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köszönrő v Tanulni sohasem késő! 


Ismernek Önök szoftverfejlesztőt? Vagy eset- 
leg Önök pont azok? Akkor bizonyára tudják, 
hogy a szoftverfejlesztők általában megszál- 
lott emberek. Nehezebbnél lehetetlenebb 
feladatokkal kell szembenézniük nap mint 
nap, és eközben olyan problémákba futnak 
bele, amelyekhez úgy érzik, nincs segítségük. 
Éjszakákat töltenek egy megoldhatatlannak 
tűnő feladat megoldásán, hogy a rákövetke- 
ző nap már egy újabbon törhessék a fejüket. 
A lényeg a kihívás, a jutalom, a megoldott 
probléma felett érzett dicsőség, illetve az el- 
készült, működő alkalmazás által nyújtott alkotói öröm. 

Az a szerencsés fejlesztő, akinek nem lebegnek a határidő 
bárdjai a nyaka felett valóban ezt érzi, és élvezi a fejlesztést. 
Azonban a határidők mindig CurrentDay-1-re vannak datálva. 
A forrongó, öles léptekkel haladó piac kíméletlen tempót dik- 
tál, és emellett, természetesen minden fejlesztő cég a legú- 
jabb technológiát szeretné latba vetni a fejlesztések során. 
Még így is sokszor előfordul, hogy mire elkészül a szuper cso- 
da rendszer, már 25 új technológia döngeti a kapukat, még 
hatékonyabb, még egyszerűbb, még sokkal többet tudó lehe- 
tőségekkel kecsegtetve. 10 évvel ezelőtt egy C programozó a 
nyelvtudásával úgy érezhette, hogy előtte hever a szakma, és 
minden számítástechnikai problémát képes megoldani. Egy 
picit azért megváltozott a világ, nem? Delphi, Basic, Java, 
Python, Perl, PHP, csak hogy a legismertebb nyelveket emle- 
gessem. És akkor még nem is mertem szólni a Ctt-ról, amibe 
akár tetszik akár nem, hamarosan minden Microsoft techno- 
lógiával foglalkozó fejlesztőnek bele kell kóstolnia. 

De a nyelv, a szintakszis csak egy dolog, amit pár nap alatt el 
lehet sajátítani. Az igazi kihívást mindig a nyelvek mögött ál- 
ló eljárásgyűjtemények, programkönyvtárak, programozási ke- 
retrendszerek megismerése jelenti. Ezekkel már éveket el lehet 
tölteni, és mégsem ismerünk minden benne található lehető- 
séget. A mai szoftverek írásakor eléggé háttérbe szorult az al- 
goritmusok ismeretének jelentősége, sokkal inkább fontos, 
hogy a programtervező megtalálja azokat az eszközöket, ame- 
lyek egy adott probléma megoldására a leghatékonyabbak. 
Azaz a fejlesztő amellett, hogy dolgozik, még valamikor meg 
is kellene tanulnia az új eszközökben rejlő lehetőségeket, 
hogy egyáltalán tudja, mikor mihez nyúljon (a fején kívül). 
Gyakorlatból mondom, hogy az éles projektek által diktált 
tempó és a tudás megszerzésére fordítandó idő hadilábon áll 
egymással, és igen nehéz egy fejlesztőnek vagy projektme- 
nedzsernek a kettőt összeegyeztetni. A határidő hajtja, de a 
feladatot csak akkor tudja megoldani, ha közben valahogyan 
megtanulja az új technológiákat. De arra meg nincs ideje, 
ráadásul, ha egy projektben 15 embernek kell ugyanazt 
megtanulni, akkor mind a 15 ember rá kell szánja az időt az 
információk összegyűjtésére, értelmezésére. 

Azt mondják, hogy az Interneten minden fenn van, és in- 
gyen bármit meg lehet róla tanulni. Ez így igaz, ha valaki 
szabadidejében tanul. Azonban munkaidőben ketyeg az óra, 
és az ügyfél - joggal - nem akar azért fizetni, hogy a 
megoldásszállító vagy a saját emberei a munkaidejük felét 
improduktív" tanulással töltsék. Nyilván egy embernél ez 
nem annyira problémás, csakhogy minden fejlesztőnek rá 
kell szánnia az idejét a tanulásra, és sok ember, sok pénz. 
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Szinte minden elérhető a web-en, ami nagy segítség, de ez 
azt is jelenti, hogy ki kell bányászni a hasznos információt 
a sok lényegtelen közül. Lehet hogy egy problémára a vá- 
lasz 2 programsor vagy egy függvény nevének az ismerete, 
de mire megvan a függvény, három nap elment a keresgé- 
léssel. Sajnos az a tipikus a szoftverfejlesztésben, hogy na- 
ponta jönnek ilyen egyperces problémák, majd a kétnapos 
keresések az információtengerben. 

E dilemma forrása az információáradat strukturálatlansága. 
Persze mind a Microsoft, mind más cégek rendszerezik az 
általuk kibocsátott információt, technológiai ismereteket, 
de az ő csoportosításuk egyfajta logikát tükröz, amire vagy 
ráérez az információéhes programozó, vagy nem. 

A probléma az, hogy természetes intelligenciára van szük- 
ség a keresési folyamatban, az információbányászatban, 
amelyet nem tudnak helyettesíteni a keresőprogramok. Le- 
het, hogy 50 cikk szól egy problémakörről, de abból esetleg 
csak 3 tartalmaz értékes információt, a többi csak 
ugyanazokat a tényeket ismételgeti. A lényeges informá- 
ciók kiválogatása és csoportosítása az, amivel minden 
egyes programozónak meg kell birkóznia, és el kell töltenie 
vele az idejét. De miért kell ugyanarra a feladatra minden- 
kinek időt rászánni? Hol van itt a hatékonyság? 

És itt jönnek a képbe az oktatóközpontok. Az oktatók 
feladata az, hogy minden lehetséges forrásból összeszedjék 
a lényeges információkat, és kiválogassák azokat az értéke- 
ket, amelyek hatékonyan támogatják a fejlesztők, informa- 
tikai szakemberek munkáját. 

A NetAcademia célkitűzésének tekinti, hogy összefogja a 
magyar fejlesztői társadalmat, és olyan professzionális kép- 
zésekkel, fórumokkal és szakembergárdával segítse a fej- 
lesztők munkáját, amelyek segítségével a programozók, 
szoftvertervezők rövid idő alatt igen magas szinten művel- 
hetik a munkájukat. A fejlesztők jól járnak, mert pár napos 
képzéssel olyan technológiákat lesznek képesek használat- 
ba venni, amelyekről addig még csak nem is hallottak. A 
munkáltatók örülnek, mert az alkalmazottak nem az Inter- 
neten töltik az idejüket megoldások után keresgélve, ha- 
nem a feladatra koncentrálnak, így több idejük marad a 
tényleges munkára. S végül a megrendelők örülhetnek leg- 
jobban, mert modern, határidőre elkészülő, jól megterve- 
zett és hatékony alkalmazást kapnak. 

Nem ígérjük, hogy a tanfolyamainkat elvégezve programozó- 
zsenit faragunk mindenkiből. Nem ígérjük, hogy a hallgatók 
egy-egy tanfolyamot elvégezve az MSDN használata nélkül 
álmukból felkeltve is fújni fogják a Common Run Time Libra- 
ry összes függvényét. Ígérjük viszont, hogy hallgatóink a 
tanfolyamok után képesek lesznek kiválasztani a feladathoz 
legmegfelelőbb technológiát, tudni fogják mihez nyúljanak 
egy-egy probléma megoldásához, és nem fognak hetekig 
vakvágányon haladni információhiány miatt. 


A legjobbakat tanítjuk, a legjobb, legújabb dolgokra. 


Soczó Zsolt MCSE, MCSD, MCDBA 
Zsolt.Soczo(onetacademia.net 
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vág malj B ötlness Megjelent a Small Business 
rver Server 2000 

A Microsoft bejelentette a Small Business Server 2000 meg- 
jelenését [1], amely a kisvállalatok számára készült hálózati 
megoldás harmadik generációs verziója. A korábbi vevők és a 
technológiaszolgáltatók visszajelzéseinek megfelelően a 
Small Business Server eszközei előre tervezhető, integrált te- 
lepítést biztosítanak, lehetővé teszik, hogy a cégek kihasz- 
nálják az Internet nyújtotta lehetőségeket, erősítik a cég ve- 
vőkapcsolatait és növelik az alkalmazottak termelékenysé- 
gét. A Small Business Server 2000 kimondottan az 50-nél ke- 
vesebb PC-vel rendelkező vállalatok számára készült. Tartal- 
mazza a Windows 2000 Server-t és a .NET Server megoldások 
és biztonságos, megosztott Internet hozzáférés) . 

Katy Hunter, a Windows .NET Server Division termékmene- 
dzsere szerint ,a Small Business Server 2000 lehetővé teszi, 
hogy a kisvállalat vezetősége egyetlen termék licencelésé- 
vel úgy elégítse ki a hálózati, kommunikációs, együttműkö- 
dési, mobilitási és Internetes igényeket, hogy a kifizetett 
árért igen nagy értékű ellenszolgáltatást kap. Ez a termék a 
vezetőség rendelkezésére bocsátja azokat az eszközöket, 
amelyekkel kihasználhatók az Internet lehetőségei, hogy 
így a cég jobban kiszolgálhassa a vevőket." 


A Small Business Server a következő összetevőkől áll [2]: 

2 Windows 2000 Server, Standard Edition, Service Pack 1-gyel 

2 Exchange 2000 Server, Standard Edition 

-2 Microsoft Internet Security and Acceleration Server 
2000, Standard 

8 Microsoft SOL Server 2000, Standard Edition 

-? Megosztott faxszolgáltatás 

I Megosztott modemszolgáltatás 

2 Microsoft FrontPage 2000 

Windows Terminal Services 


Itt a BackOffice Server 2000 
Microsoft" S is! 

BarkOffice Server [3] A BackOffice Server 2000 a 
Microsoft Windows? 2000 operációs rendszer legfontosabb ki- 
szolgálócsomagjának új verziója. A BackOffice Server-rel ke- 
vesebb költséggel és egyszerűbben hozhatók létre, telepíthe- 
tők és kezelhetők a vállalati osztályok és a közepes méretű cé- 
gek integrált és méretezhető IT megoldásai. Ez a verzió integ- 
rálja a Windows 2000 Server-t és az összetevő termékek leg- 
frissebb Standard verzióit, az infrastrukturális és alkalmazás- 
szolgáltatások széles körét biztosítja, így címtárat, hálózati 
szolgáltatásokat, Web-alkalmazásokat, adatbázisokat, üzenet- 
kezelést és együttműködést, Internet proxy-t és tűzfalat, host 
integrációt. 
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SBS és 


BackOffice 2000 


A BackoOffice Server 2000 a következő összetevőkből áll: 
Microsoft Windows 2000 Server, Service Pack 1-gyel 
b Microsoft SOL Server 2000, Standard Edition 
0 Microsoft Exchange 2000 Server 
b Microsoft Internet Security and Acceleration Server 2000 
-0 Microsoft Systems Management Server 2.0, Service Pack 
2-vel 

"0 Microsoft Host Integration Server 2000 
"0 A Microsoft FrontPage 2000 SR-1 egyfelhasználós verziója 
) Egyéb tulajdonságok: intelligens, a helyzethez idomuló 
telepítő, MultiServer Planning Wizard, BackOffice Server 
Management Consoles és az ahhoz tartozó Varázslók, 
Health Monitor 2.1 és Server Status Views and Reports. 

7 Microsofr 

j mg 

Mit kapunk a Visio 2002-vel? se] Visio 
A Visio 2002 béta kipróbálásakor a 


következő újdonságokkal találkozhatunk: 

PI Élesebb diagramok. A Visio 2002 szebb grafikát, szöveget 
és színeket biztosít, valamint lehetővé teszi, hogy egyéb 
forrásból származó képeket importáljunk és szerkesszünk. 

"0 Microsoft Office család alkalmazás. A Visio 2002 segít 
abban, hogy a közös funkciókkal és az együttműködési 
tulajdonságokkal hatékonyabban dolgozhassunk a köz- 
ismert Office felületen. 

-0 Szoros webintegráció. Az új online erőforrásokkal a fel- 
használók jobban kihasználhatják a Visio 2002-t. Szebb és 
hatékonyabb diagrammokat is közzétehetünk a weben. 

0 Továbbfejlesztett telepítés és karbantartás. Az új to- 

vábbfejlesztett tulajdonságok leegyszerűsítik a Visio 

2002 telepítését és karbantartását a vállalatban. 

Nagyobb termelékenység. A Visio 2002 továbbfejlesz- 

tett tulajdonságlistázást és adatbázis kapcsolatot, ha- 

tékonyabb keresési lehetőségeket és használhatóbb 
munkakörnyezetet nyújt. 

"0 Testreszabhatóság. A fejlesztők a COM add-in-ek, az új 
XML fájlformátum és a több mint 90 új automatizálási 
módszer segítségével rugalmasabban hozhatnak létre 
egyedi Visio alkalmazásokat. 


Visio 2002 előzetes 
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a Egy hálózati diagram a Visio 2002-ben. További áb- 
rák a Visio 2002 galériában láthatók [4] 


Érdemes ellátogatni a Visio 2002 webhelyére [5], ahol a 
béta meg is rendelhető. 


Hamarosan itt a Windows 2000 Service Pack 2 

A hivatalos források szerint 2001 első negyedévében, azaz 
még márciusban megjelenik a Windows 2000 Service Pack 
2. Ez azért is valószínű, mert a weben egyre több helyen 
található meg az SP2-ben javított hibák listája, egy példa: 
[6] Azt már előre lehet tudni, hogy a Service Pack 2 tele- 
pítésével immár minden Windows a 128 bites biztonsági 
alrendszert használja majd, és nem is lesz lehetőség 
visszatérni az 56 bites változathoz. Az SP2 CD az SP1-hez 
hasonlóan tartalmazza majd a külön már régebben letölt- 
hető [7] Terminal Services Advanced Client-et (TSAC), ami 
a webes és MMC-be illesztett terminálügyfél használatát 
teszi lehetővé. Egyes madarak azt csicsergik, hogy az SP2 
jóvoltából az eddig csak a Datacenter Server-ben található 
Winsock Direct [8] beköltözik az Advanced Server-be is. Az 
SP2 béta méretei kicsit ijesztőek: a telepített SP2 Profes- 
sional-on 180, Server-en 235 megabájtott foglal, ha a 
visszautat is szeretnénk meghagyni magunknak (unin- 
stall), az további 200, illetve 260 megabájtunkba kerül. A 
telepítés közben átmenetileg további 190/250 megabájt- 
nyi helyre van szükség 
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MINÉL TÖBB PÉNZT ELKÖL- 
TETNI A CÉGGEL, AZÉRT, 
HOGY MINÉL KEVESEBB 
MUNKÁJA LEGYEN. 


TULAJDONKÉPPEN 
MI A RENDSZER- 
GAZDA DOLGA? 





HÍREK...HÍREK...HÍREK... 


Reguests from unmodified user-level applicatioi 
that use Winsock and TCP/IP 
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System area network (SAN) 


5 WinSock Direct: SP2 után Advanced Server-ben is? 


[11 http://www.microsoft.com/presspass/features/ 
2001/febO1/feb21sbs.asp 

[2] http://www.microsoft.com/sbserver/ 

[3] http://www.microsoft.com/backofficeserver/ 

inf jew.htm 

[4] http://www.microsoft.com/presspass/events/ 
visio2002/gallery.asp 

[5] http://www.microsoft.com/office/visio/2002beta.htm 

[6] http;, ivewin. s.shtml 

[7] http://www.microsoft.com/windows2000/downloads/ 
recommended/TSAC/default.asp 

[8] http://www.microsoft.com/WINDOWS2000/en/ 
datacenter/help/WSD Def.htm 





NEM. AZ ÍT IPAR GONDOSKO- 
DIK RÓLA, HOGY A FOLYA- 
MAT VÉGTELEN-HATÁRÉRTÉK 
FELADAT LEGYEN. 


DE EKKOR ELJÖN EGY OLYAN 
IDŐSZAK, AMIKOR A REND- 
SZERGAZDÁNAK SEMMI MUN- 
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WINDOwS 2000 


E havi NetMonozásunkat nem a NetMonnal a kézben kezdjük. A 
TCP csatorna jellegzetességeinek megfigyeléséhez előbb át kell 
esnünk egy kis elméleten. A múltkori részben többször elénk ke- 
rült (az IP fejlécben, az Ethemet keretben, az ICMP Echoban) a 
csomagok integritását végző ellenőrzőösszeg, a checksum. Nem 
igazán fejtettem ki a védelem mibenlétét, de nem is lett volna 
miről írni: a checksumkezelés igen primitív algoritmus alapján 
zajlik. A hálózati forgalmat generáló és irányító eszközökön 
minden egyes beérkezett csomagon kiszámítódik az ellenőrző- 
összeg. Ha a kiszámított érték megegyezik azzal, ami a csomag- 
ban is olvasható, a csomag életben maradhat, ha pedig nem 
egyezik, vesszen a hibás, deformálódott egyed. 


EL lehet tűnődni azon, hogy vajon ez a hibakezelés elég in- 
telligens-e, vajon mindig egyértelműen törölni kell-e a hibás 
csomagokat (a Voice Over IP például , jobban megy" még hi- 
bás csomagokkal is, mint újraküldött hibátlanokkal, mert a 
csomagismétlés késleltetése sokkal zavaróbb a beszédértésben, 
mint holmi bithibák). 


Maradjunk annyiban, hogy az alapértelmezett checksumkeze- 
lés elég drasztikus módon ugyan, de eltávolítja a hibás cso- 
magokat a hálózatról. 
Vizsgáljuk meg, mekkora az a maximális hiba, amit a check- 
sum még elvisel. Ez az összegszámító algoritmustól függ. Az 
Ethernet kártyák által használt CRC (Cyclic Redundance Code) 
például akár egyetlenegy bit átbillenését is észleli. 
"0 Ha átbillen egy bit - elromlik az ellenőrzőösszeg 
"0 Ha elromlik az ellenőrzőösszeg - eldobódik a csomag 
"? Ha eldobódik a csomag - elvész az átvinni kívánt adat- 
mennyiségből egy jókora (1514 bájt) darab. 
Ki, és hogyan fogja ezt észlelni, korrigálni, pótolni? Az IP? 
Ugyan! Azt már a Tracert esetében is láttuk, hogy ha kicsi 
TTL-lel indítottuk útjára, elhullott, mint szivacsos agyhártya- 
gyulladásban szenvedő nagy négylábú barom. Bithiba esetén 
sem lesz jobb a helyzet - elhullik. 
A kieső csomagok pótlására akár maga a hálózati szolgálta- 
tást igénybevevő alkalmazás is vállalkozhatna - ha tudatá- 
ban lenne ennek a nehéz feladatnak. De vegyünk egy Excelt. 
Annak bizony egyre megy, hogy a FONTOS.XLS-t vajon helyi 
lemezre, vagy hálózati kiszolgálóra mentjük! A második jelöl- 
tünk e feladat ellátására az operációs rendszer (pl. Windows 
2000) lehetne, ami részben igaz is: az operációs rendszer 
egyik meghajtója, a tcpip.sys felel a csomagelvesztések me- 
net közbeni korrekciójáért, a hiányzó , alkatrész" pótlásáért. 
Ennek érdekében a feladó oldalán a tcpip.sys minden egyes 
csomagot besorszámoz, hogy a fogadó oldalán csücsülő 
tcpip.sys a sorszámok alapján pontosan észlelhesse, ha kima- 
rad egy-egy csomag. Az eredményességről vagy eredményte- 
lenségről pedig rendszeres visszajelzést küld a feladónak 
(ACK, acknowledgement). 
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A TCP csatorna 

Mit hívunk TCP csatornának? Csak nem ezt a teljesen primitív 
sorszámozós rendszert? De igen. És bármilyen furcsa lehet, a 
maga ,bonyolultságában" ez a rendszer meglepően jó hatás- 
fokkal működik, s messze többet tud, mint csomagelveszíté- 
seket korrigálni. Észreveszi ugyanis a csomagsorrend cserét is, 
valamint a csomagok megduplázódása sem marad rejtve. 


Kérdés, melyre a tech.netOlyris.netacademia.net című lev- 
listán várom a válaszokat: hogyan képzelhető el csomagdup- 
lázódás? Talán dadog valamelyik router? 


A TCP csatornát úgy célszerű elképzelnünk, mint egy csőpostát, 
amely két számítógépet úgy köt össze, hogy amit a cső egyik 
végén bedobok, az a másik végén épen, egyben bukkan fel. 


L] L] 








a Egy TCP csatorna , idealista" ábrázolása 


A cső feladata a szállítás garantálása, illetve annak jelentése, 
hogy ha a szállítás nem valósítható meg. Sokszor mondják, 
hogy a TCP/IP katonai rendszer. Ezt a badar tévhitet a TCP 
csatorna azon viselkedése is erősíti, hogy ha romlik a vonalak 
minősége, akkor a cső lelassul (iszonyatosan le tud lassulni!) , 
de NEM adja fel! Mintha bizony államtitkot kellene eljuttatnia 
a végpontra! Addig kínlódik, új utakat keres(nek helyette a 
routerek) , ismételget, amíg van benne szusz. Ha pedig min- 
den lehetőség kimerült, akkor jelenti alásan, hogy a haditer- 
vet nem sikerült teljesítenie. Olyan nincs, hogy a TCP félreve- 
zetne minket, és úgy tenne, mintha minden rendben menne. 


Itt most megint elfilozofálhatnánk azon, hogy vajon minden 
esetben érdemes-e bármi áron, vérző fejjel leszállítani az üzene- 
tet, vagy értelmesebb lenne talán feladni a próbálkozást, ha az 
átbocsátóképesség X bit/s alá csökken. OoS, Ouality of Service! 


Miből áll tehát a TCP csatorna? Ezernyi sorszámozott csomag- 
ból, melyek oda-vissza szaladgálnak a kommunikáló felek kö- 
zött. Némelyikben adat van, némelyikben csak egy ACK, és 
mindegyikük (legalábbis Etherneten) maximum 1514 bájt 
nagyságú. Egyedi csomagok ezrei... 

Vajon azonos útvonalon haladnak az Interneten át? Nyilván 
nem. Helyesebben: akár azonos útvonalon is haladhatnak, de 
ezt a közbenső útválasztók és vonalak pillanatnyi , hangulata" 
erőteljesen befolyásolja. Az előbbi, idealista ábránd helyett a 
valóságot sokkal hűségesebben adja vissza az alábbi ábra: 
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a Egy TCP csatorna , valósághű" ábrázolása 


Ha még azt is figyelembe vesszük, hogy egy gépen a nyitott 
TCP csatornák száma nem 1, hanem akármennyi, akkor 
az ábrán úgy néznének ki a gépek, mint egy-egy polip: 
egyik karja a www.netacademia.net-re tekeredik, másik a 
www.microsoft.com-ra, harmadik a tartományvezérlőre stb. 


Portok 

Ha egy számítógépnek ennyi karja lehet, akkor vajon miért 
nem zavarodik bele abba, melyik karja merre nyúlik? Vegyük 
először egy internetező-böngésző felhasználó esetét. A célgép 
IP címe vajon segít a sok-sok csatorna egyedi azonosításában? 
Csak addig segít, amíg egy címre csak egyetlenegy TCP kapcso- 
latot (csatornát) nyitunk. Ez azonban nem mindig van így, 
hisz senki sem tilthatja meg nekünk, hogy egy weblapra öt 
böngészőt nyissunk! Vagy vegyük egy webkiszolgáló esetét. 
Egyszerre mondjuk tízezer kapcsolatot szolgál ki. Honnan tud- 
ja, hogy melyik csőbe mit kell dobni? A feladók IP címe segít? 
A válasz ugyanaz: ha elindítok tizennyolc böngészőt egyazon 
gépről ugyanarra a webkiszolgálóra, akkor e tizennyolc csator- 
nát hogyan fogjuk tudni megkülönböztetni egymástól? 

Még egy eszmefuttatás: ha egy Internetre kihelyezett gépen 
nemcsak webkiszolgáló fut, hanem FTP, Telnet, POP3 és még 
ki tudja mi minden, vajon hogyan címzem meg az egyes al- 
kalmazásokat? Hogy van az, hogy a böngésző mindig a web- 
kiszolgálót szólítja meg? Mindig? Tévedés! Tessék így kezde- 
ni a begépelt URL-t: ftp://www.netacademia.net. 

Mi az ördög? Ftpzik? Ftpzik! 

A csatornát általában nem tudjuk a végpontjainak IP címé- 
vel egyértelműen megadni. Szükség van még egy azonosító- 
ra, amely segít megkülönböztetni az azonos gépről érkező 
kapcsolatokat egymástól, segít elválasztani a HTTP kérést az 
SMTP-től, segít egy távoli gépen ,eltalálni" a sok-sok futó 
szolgáltatás közül pont azt, amire vágyunk: ez a portszám. 
1. Villámkérdés: Hányas porton megy a webszerver? 

2. Villámkérdés: Hányas porton megy az Internet Explorer? 


1. villámválasz 

Az első kérdésre mindenki fújja a választ: 80-as. Így igaz. De 
miért pont a 80-ason találjuk a webkiszolgálókat? A 80-as 
úgynevezett well-known (jól ismert, közismert) port, és azért 
pont nyolcvan, hogy a világ összes publikus számítógépén 
mindig megtaláljuk a webszolgáltatást. Nem kell gondolkod- 
ni, paraméterezni és programozni: ha egy gépen a nyolcva- 
nas számú ajtón (porton) megyünk be, akkor ideális, szét- 
nem-konfigurált esetben a webkiszolálón vagyunk. 
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MICROSOFT NETWORK MONITOR (IV. RÉSZ) 
HTTP / SMTP FTP 
UDP TCP ICMP 
ARP IP IPX 
Ethernet! 
1.1.1.1:2351 7.7.7.T:4321 
2.2.2.2:1431 1-7-7-T23234 
2.2.2.2:4124  4.4.4.4:1234 5.5.5.5:1234 





5 Portok, kapcsolatok 


Hány kapcsolat építhető egy portra? A fenti ábra tanúsága 
szerint egészen pontosan X. Az egyetlen követelmény, hogy 
a kapcsolatok megkülönböztethetők legyenek. Mivel ezen az 
ábrán (szinte) mindegyik ugyanarra a portra fut be, ezért a 
szerveroldali végük alapján nem különböztethetők meg - így 
nyilván az alsó, , rojtos" végük különbözik. Különböző IP cí- 
mekről jönnek, vagy ha azonos címről, akkor külön portról. 
A 80-as port egyébként nem szentírás, a legtöbb szolgálta- 
tás átállítható, más portra helyezhető. De ezzel el is veszít- 
jük, ha csak valaki meg nem súgja a helyes portszámot. Ha 
valaki pl. a 8080-as portra tesz webszolgáltatást, akkor azt 
így kell becserkészni: http://www.matav.hu:8080. Ez a 
módja annak, hogy a böngészőnk más porton kopogtasson. 


2. villámválasz 
A második kérdésre is sokan rávágják: 80-as :-0 No ez nem 
igaz! Hisz ha nyitok két Explorert pont ugyanarra a webki- 
szolgálóra, sőt, ugyanarra a lapra, ezt a két kapcsolatot is 
meg kell tudnom különböztetni, hisz az egyik lapon teljesen 
másra kattinthatok, mint a másikon, s a két böngészőm eb- 
be nem zavarodhat bele! A böngészők és egyéb ügyfélszoft- 
verek úgynevezett kliensporton ,ülnek"7, aminek száma 
egyedi, és 1024-nél nagyobb. Az alábbi ábrán egy olyan gé- 
pet látunk, amelyen egyszerre X darab IE, és Y darab 
Netscape Navigator fut párhuzamosan, békességben. 
1344 1345 1346 1347 1348 
IES5.5 IES.5 ( (TE5.5 Netscape 6 





Netscape 6 



























































Ethernet 











a , Ötszáz" böngésző egy gépen: egyedi portszámokon 
futnak! 


Kijelentésem igazságát a 
netstat -p TCP 


utasítás begépelésével ellenőrizhetik bátrabb olvasóim. 
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Tűzfalak, proxyk 

Az eddigi ismeretekkel felvértezve megkísérelhetjük megérteni, 
mit is jelent az, amikor a tűzfal 80-as portja nyitva van. A tűz- 
falakon átmenő forgalomnak ugyanis meghatározott iránya 
van: lehet befelé, és kifelé igyekvő csomagunk. Ezen túl érde- 
mes megfigyelnünk az így áthaladó csomag feladó és fogadó 
portszámát. Csak a 80-as porti forgalomnak négy változata van! 


Feladó 


Fogadó A forgalom 
portja portja típusa 
gé ú weblapkérésre külső 
1 Befelé 80 kliensport kiszolgáló válasza 
ej E a belső webkiszolgáló 
2 Kifelé 80 kliensport kejizátő 
a belső 
8 Befelé kliensport 80 webkiszolgálót 
kívülről zaklatják 
ús jú E weblapkérés bentről, 
4 — Kifelé kliensport 80 RT ed 


Ebből a négyből azok a tűzfalak, amelyek kizárólag a kifelé irá- 
nyuló webböngészést engedik, csak az első és a negyedik cso- 


magtípust eresztik át, sőt, az okosabbak csak olyan elsőt (külső 


választ) , amely válasz egy negyedikre (weblapkérés) . Ez a tűzfal- 
típus tehát a rajta átívelő TCP csatornák kinyitására és elzárásá- 
ra képes. Ha a csatornát engedélyezi, akkor visszavonul, és az 
átmenő forgalmat már nem ellenőrzi. Jöhetnek a vírusok! 

Egy jobb tűzfal nemcsak nyit/zár, hanem megpróbálja az 
átmenő forgalmat értelmezni, szűrni, hogy a nyitott csator- 
nákon át ne lehessen mást forgalmazni, mint ami oda ,va- 
ló": a 80-ason csak HTTP, a 25-ön kizárólag SMTP mehessen 
stb. Az ilyen típusú tűzfalakat más néven proxynak is hív- 
ják. Ilyenkor a kliens nem a végcéllal épít ki TCP csatornát, 
hanem a tűzfallal. Az minden csomagot kiszed a csőből, és 
ha értelmesnek találja, továbbküldi kifelé, és egy, a kliens 
helyett (proxyzhelyettesítő) általa felépített TCP csatorná- 
ba dobálja bele az adatokat. Ilyenkor a feladó és a fogadó 
valójában sohasem találkozik közvetlenül egymással. 


Szekvenciaszámok, háromutas kézfogás 

Az utolsó kérdés a TCP sorszámozásának megvizsgálása. Em- 

lítettem, hogy a TCP minden egyes csomagot besorszámoz, 

mielőtt elküldené. Nem említettem, de sejthető, hogy a visszi- 
rányú hálózati forgalom is sorszámozott: minden ACK egyedi 

sorszámmal bír. Mielőtt azonban a felek megkezdhetnék a 

kommunikációt, meg kell ismerniük egymás kezdősorszámát. 

Nem, nem egytől indulnak, hanem random számokat használ- 

nak - ennek biztonságtechnikai okai vannak. Azt a folyama- 

tot, amikor a partnerek kicserélik egymás szekvenciaszámát, 
kézfogásnak hívjuk. Én inkább csip-csip csókának hívnám, 
mert olyan ez a három csomag, mintha egymás kezére tennék 
egymás kezét, de sajnos a W3C nem fogadta el e terminológiai 
javaslatomat :( Az angol elnevezés továbbra is three-way 
handshake, pedig a chip-chip-choka mennyivel találóbb lenne! 

Körülbelül így zajlik a folyamat: 

1. A feladó kapcsolatot kezdeményez a fogadógéppel a 
megcélzott (mondjuk 80-as) porton, és elküldi saját kez- 
dősorszámát. Ezt a csomagot világosan meg lehet külön- 
böztetni a Network Monitorban a benne bebillentett , 5" 
flagről. (S, SYN-Synchronize Seguence Numbers) . Így fog 
kinézni a Network Monitorban: 

szeli 
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2. A fogadó (ha van a megszólított porton szolgáltatás) pozitív 
választ küld, egy ACK formájában. Az ACK mindig azt mutat- 
ja, hogy a partner melyik szekvenciaszámtól folytathatja az 
adást. Így ez az ACK az előbb megkapott szám plusz egyet 
(5-1) fog tartalmazni. Jelentése: oké, innentől jöhet! To- 
vábbá - sávtakarékossági célból még ugyanebben a csomag- 
ban - ő is elküldi saját kezdő szekvenciaszámát, amivel pe- 
dig a tőle kiinduló csomagokat sorszámozni fogja: 

A5 

3. Végül az eredeti kezdeményező küld egy ACK-ot, s ezzel a 

csatorna felépült. 
dos aa 

E három csomag után következhet az oly fontos adatok átvi- 

tele. Miután az összes adat átment, a csatorna bontása szin- 

tén csip-csip csóka módszerrel történik. Ekkor nem az ,S§", 

hanem az ,F" flag segít, melynek jelentése: No more data 

from sender. A lebontás így néz ki: 





É 
dd 

Ass 
Ezzel a felek illendőképpen elbúcsúztak egymástól, ásó, ka- 
pa, nagyharang. Lássuk mindezt élőben! 


Nyitott 80-as port 
Az első NetMon fájl, amit mutatok, a nyitott80.cap nevet vi- 
seli, és helye szokásosan az újság weblapjának feladatok al- 
könyvtárában található. 1,5k csupán, érdemes letölteni, 
hogy vizsgálatainkat együtt MSZEZSÉszátó 


CERSHST BEEE 


su] :Iels] S/EISET ele] slel alz[eT € 2] 


Protocol [ Description 
Bone Security Check 
0x27:Std Ory to 
0x27:Std Ory Re 


ETET 















030000000002 
244120000100 DNS 
000001000000 DNS 
2A4120000100 TCP 
000001000000 TCP 
244120000100 TCP 
030000000002 


0.921316 
6.389124 
6.659510 
6.6795328 
6.8998532 
6.899852 
10.935616 


244120524153 
900001000000 
244120000100 
000001000000 
244120000100 
000001000000 
ZA412OSZ4153 








Tanaon 





Bone 


(Network Monitor Capture Statistics P. Fe: 8/ő 4 





a A TCP csatorna felépítése 


Az ábrán jól látható az előbb magyarázott háromutas kéz- 
fogás, ahol a description mezőben egymás alatt három sor- 
ban ezt látjuk: 


dass 
Az előtte lévő két DNS sor egy Standard Ouery és egy Res- 
ponse. Ezeket ismertnek veszem csakúgy, mint a Bone proto- 
kollt. Hogy miért ismertek? Mert aki nem a negyedik résztől 
kezdte olvasni sorozatomat, annak ez már a könyökén jön ki. 
Nyissuk meg a ....5S. csomagot, lássuk mi minden van benne! 
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éli] : RE] 8] FlElsol sir] le] áalrilrr] 0] ? 
TEGKRIJ TERE Sze MAC Adar [Dsc MaC Adar] Proroco1 [Descripcion 2] 
4 6.679538  000001000000 244120000100 TCP 7 Het 

5 6.999853 — ZM4120000100 000001000000 

7 10.935616 ZA4IZOSZ4LS3 030000000002 

ee ez sz ij 

x[BFrame: Base frame properties 

[BETHEPRNET: ETYPE 5 0x0800 : Protoco) 

iGIP: ID OZ6EA; Proto z TCP; Legf 48 


eTCP 













: Seguence Number 2 44 
: Acknovledgement Number z 0 (0x0) 

: Data Ottset - 28 (0x1C) 

: Reserved : 0 (0x0000) 

: Flags 5 0x02 : ....§. 

: Windou : 8760 (0x2238) 

: Checksum 5 0x438B8 

: Urgent Pointer " 0 (050) 
: Options 





D0000020 
9000030 22 39 43 B8 00 00 02 04 05 B4 01 01 04 02 


Le] 


08 24 04 74 LA AI 43 B9 00 00 00 00 70 02 








Destination port number 


D Synchronize Seguence Numbers 





Ethernetben IP-ben TCP. A feladó portszáma 0, a 0x047A 
egy kliensport, hisz ez a szám nagyobb, mint 1024. A célgé- 
pen pedig a sokat emlegetett 80-as portot, vagyis egy web- 
kiszolgálót céloztunk meg. Ezt a portot a NetMon is ismeri 
(nem hiába well-known), és oda is írja szépen a protokoll ne- 
vét 2, míg a hexa panelen egy 0x50(-80!) látványának ör- 
vendezhetünk. A szekvenciaszámról lesír, hogy random érték 
8), az ACK pedig azért nulla, mert ez a legelső csomag ezen 
csatorna életében, nem tartunk még a visszajelzéseknél. 

A flag bitjei a következők lehetnek: 

9 1) z Urgent data 

Acknowledgement field significant 

z Push function 









ő Reset 
kéztégi 0. - Synchronize seguence numbers 
aténsnál 0 - No more data from sender 


A TCP-nek is van ellenőrzőösszege, ahogy az eddigi összes ré- 
tegnek volt. A Window £ érték - ha nagyon pongyolán sze- 
retnék fogalmazni - annyi jelent, hogy 8760 bájt küldhető át 
a hálón visszajelzés, ACK megvárása nélkül. Lássuk a választ! 
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ri éz NK ep. SZ et 51) 
slial : ml 8] EB ol sleal elél sali] 0]? 
Frane [/Tine Sre MAC Addr [Dst HAC Adár Description 4 
4 6.679538 — 000001000000 2A4120000100 TCP 2 len: 

s 6.899852 — 244120000100 000001000000 TCP len: 

6 6.899853 — 000001000000 2A4120090100 TCP len: 

7 10.925616 ZA4IZOSZ4153 030000000002 Bone Security Chec 
kej Ez e édi ; 
jeFrane: Base frame propertiez a 
xKÖRTHERNET: ETYPE 5 0x0800 : Protocol : IP: DOD Internet Protocol 


IP: 
eTCP: 


ID 5 Ox4DS7; Proto : 
elkerse AGAS 07 
Source Port - Hypei 
Destínation Port - 


TCP; Len: 48 
seg: 302666183-302666182, ack: 
TCP: ext Transfer Protocol 

TCP: Oz047A 


: Seguence Number - 302666182 (OxIZOAS1C?) (65) 
: keknovledgenent Number " 446776250 (OxlAAL43BAT 
: Data Offset - 28 (0x1C) 


446776250, vi 








: Window " 17520 (0x4470) 
: Checksum 5 OxBDID 

: Urgent Pointer - 0 (0x0) 
: Optáons 


4 EE E E E Ez 
/D0000020 09 24 00 50 04 7A 12 0A 51 C7 1A Al 43 BA 70 
00000320 44 70 BD 3D 00 00 02 04 05 B4 01 01 04 02 




















TCP Flags summary 





a Synchronize Seguence Numbers válasz 
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A portoknál megfigyelhető, hogy az előbbi feladóból fogadó 
lett, s a fogadóból feladó 6: a webkiszolgáló válasza a 80- 
as portról jön, és a kliensportra megy. A válaszoló webgép 
is generál egy szekvenciaszámot, amivel a tőle kimenő cso- 
magokat majd sorszámozni fogja 6. Érdekes összehasonlíta- 
ni az itteni ACK számát 0 az előző csomag szekvenciaszá- 
mával: hát nem pont egyel több? S mit várhatunk a harma- 
dik csomagtól? A feladó ismét a kliens, s ,leackolja" az it- 
teni szekvenciaszámot, így ott ez olvasható: 
Acknowledgement Number - 302666184 (0Ox120A51C8) 

Vajon hogyan fordulhatott elő, hogy e három csomag után 
végetért a móka, és nem hullott a kliensre egy Default.HTM? 
Sőt, semmi sem hullott! Ennek az az oka, hogy a fenti for- 
galmat nem Explorerrel generáltam, hanem telnettel: rácsat- 
lakoztam a távoli gép 80-as portjára, így: 


Telnet www.netacademia.net 80 
Mivel a telnet.exe nem kifejezetten webböngésző, nem küld be 


a világon semmit a kész csatornába, így az idővel lebomlik. A 
bomlás virága az alábbi DOS ablakba böffintett HTML hibaüzenet. 


Command Prompt - telnet www.netacad 


-1 488 Bad R 
Microsoft-I 
t. 18 Feb 
LETT 


(515Pi 





5 , Betelnetelek" a 80-as porton 


Valójában a telnet.exe igen jó TCP segédeszköz, ugyanis 
nem csinál mást, mint felépít egy TCP csatornát kliensport- 
ról egy távoli gép tetszőleges portjára, majd nem szól bele 
egy mukkot sem, teljesen ránk bízza a csatorna adattal tör- 
ténő ellátását. 

Zárt ajtók 

Most vizsgáljuk meg, hogyan néz ki az a hálózati forgalom, ami- 


kor olyan portra próbálunk meg csatlakozni, amely nincs nyitva. 


SL sálat e 


-.Could not open a Ill 





a , Betelnetelek" a 82-es, zárt porton 


Azt hihetnénk, hogy a zárt port meg sem mukkan, de nem 
így van, mert ha válaszra sem méltatna minket, akkor háló- 
zati hibára gyanakodva még X-szer megkísérelnénk a kap- 
csolatfelvételt. Emiatt tehát - az udvariasság jegyében - el- 
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várható, hogy ha bekopogunk mondjuk a 82-es porton, akkor 
- mint Nyuszi a Micimackóban - visszaválaszolnak, hogy 
,Nincs itthon senki". Ebből tudhatjuk, hogy tényleg üres a 
ház - ennek dacára három csatlakozási kísérlet történik, ami- 
nek az az oka, hogy sajnos nem derül ki egyértelműen a ko- 
pogtató számára, hogy mi az elutasítás oka. Az egy és oszt- 
hatatlan Reset Connection üzenet egyaránt jelenthet csukott 
portot és szoftveres elutasítást (például ha nincs reverse be- 
jegyzés az IP címünkhöz). Ennek hálózati forgalma a weben 
a csukott82.cap fájlban található, s így fest: 


Microsoft Network Monitor - [ ADOCUME HFMZEFÁZ 


lala] 
















rotocol ription 


030000000002 Bone Security Check 









1 
a a laptop 

4 3.705291 — laptop ua TCP 

s 2.945635 u laptop TCP 

6 4.406292 — laptop uuu TCP 

7 4.646636 un laptop Tep 

a 0.000000 — 000000000000  000000000000 STATS 


Fa: 28 Ze) 


ÍTCP protocol summary 


o Reset connection 


A szokásos S kérésre ebben az esetben R (Reset connection) 
a válasz, amit ezután nem is követ harmadik csomag. Tekin- 
tettel arra, hogy az elutasítás egyetlen bittel történt, sajnos 
indoklást nem találunk a csomagban. 





POP3 

Most próbáljuk ki egy valódi alkalmazás működését Telnet se- 
gítségével! Próbáljuk meg elolvasni leveleinket POP3 proto- 
kollal, ám ügyfélprogram nélkül, puszta kézzel! (Nem fogom 
végigvezetni, csak a bejelentkezésig vizsgáljuk meg a hálózati 
forgalmat. A fájl neve: pop3.cap) 


Telnet mail.netacademia.net 110 


METE 
j EIT TTEZEZOZÉ 
EEERP 
KENYLNYT 9) 
s titol 
j 


R Logon failurez 


Exchange 


MTA user name or bad password 


k Microsoft Exchange 2808 POP3 server version 6.B.4 


nnection to host lost 


to continue... 


a POP3 , puszta kézzel 


A létrejövő TCP csatornában a kiszolgáló elküldi üdvözlő üze- 
netét 8, majd várakozó álláspontra helyezkedik, parancsra 
vár. A decemberi számunkban megjelent POP3 szabványis- 
mertető alapján haladva először megadjuk a felhasználó ne- 
vét majd jelszavát 9. Ilyen felhasználó sajnos nincsen, de 
sebaj. Most nézzük a NetMont! 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 03. 


MICROSOFT NETWORK MONITOR 








(TV: KÉSZ) 
imad 
JölEle Edt Display Iools Options Window Help 











szlmaj sal 


Trame [Time 


S/ERBER elel lel alas] al 2] 


Src MAC Addr 

















Dst MAC Adar [Protocol [Description 2] 





27 20.799701  000001000000 2A4120000100 TCP . len; 
28 21.060073  244120000100 000001000000 TCP . lenr 
29 21.220216 000001000000 2A4120000100 TCP . len: 
20 22.201846 000001000000 244120000100 TCP . len: 





31 652346  2A4120000100  000001000000 TCP , len: 
37 .652346  000001000000 244120000100 TCP a len: 
33 .OSZ918  224120000100 000001000000 elkazz eg HIRE 
34 052918 000001000000 244120000100 r 
35 .453490  2A4120000100 — 000001000000 
36 702848  000001000000 244120000100 
37 094406 244120000100 000001000000 
38 .217437 — 000001000000 244120000100 
39 .577952  244120000100 —000001000000 
40 .577952  000001000000 244120000100 

.978524  244120000100 000001000000 





(Network Monitor V5.00.646 Fe: 1762 4 


o A pop3.cap fájl 


Te jó ég! Ez a két parancs 62 csomagot generált 40! Hiszen 


összesen 3-4 kérdés és válasz történt! Mi lehet ez? 


Terminálemuláció 

Eddig nem került szóba a telnet.exe valódi funkciója, szárma- 
zása. Természetesen tud TCP csatornát nyitni, de ezt azért 
teszi, hogy utána a TCP csatornát pontosan ugyanarra a cél- 
ra lehessen használni, mint a régi terminálok , hálózati" kap- 
csolatát, a soros portot - vagyis karakterek átvitelére! A Tel- 
net.exe úgy emulálja a terminálfunkciót, mintha a TCP csa- 
torna egy vacak RS-232 kábel lenne. Vagyis, ha a felhaszná- 
ló leüt egy karaktert, az már mehet is át a ,kábelen". Igen 
ám, de itt egy virtuális ,kábelről" van szó, melynek csator- 
najellegét az ide-oda küldött ACK-ok tartják fenn. Így a ka- 
rakterenkénti átküldés eléggé sajátságos sávszélesség-gaz- 
dálkodást eredményez: minden 55 bájtos TCP csomagban 
EGYETLEN bájtnyi hasznos adat utazik! 


EZTET STT TEN a T 


zD2 



















30 22.301046 000001000000 24A4120000100 TCP 
31 22.652346 2A4120000100 000001000000 TCP 





: Flags " Ox18 : -AP... a] 
TCP: Windov - 8661 (OxZ1D5) 
TCP: Checksum " OxD63D 

: Urgent Pointer 5 0 (0x0) 





m 1 (0x0001) 











00 29 06 69 40 00 80 06 34 SB D4 61 09 24 D4 61 
20 08 24 04 6C 00 6E 16 9F CD 75 OD FF 96 BF 50 18 


7A 41 20 00 01 00 00 00 01 00 00 00 08 00 15 00 "A. 
). 
; 

21 Ds 06 35 00 00 EIB tása. 


Data containedin TCP packet — FE: 30f62 





0 Number of data bytes remaining 


Csak nézzük meg szúrópróbaszerűen a Number of data bytes 
remaining-et mondjuk a 30. keretben! Egy nyamvadt ,p" be- 
tű a hasznos adat 0! A többiben pedig rendre , a", ,S", ,5", 
mm ta AT a, 10", uk". Azaz ,pass titok". Ejnye. Titkosí- 
tatlanul megy át a hálózaton a jelszavunk? Igen, nagyon sok 
alapalkalmazásnál ez így történik, ami ellen a csatorna titko- 
sításával védekezhetünk - de az SSL egy másik, hosszú tör- 
ténet. Ami pedig a sávszélesség okos ihasználását illeti - a 
telnet ebben nem jeleskedik. 
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7 bites az Internet? 

A fenti kísérlet rávilágít egy érdekes dologra. Mint ahogy a 
TCP/IP nem katonai rendszer, úgy az a közvélekedés is szín- 
tiszta badarság, hogy az Internet bizonyos zugai 7 bitesek 
lennének. Mitől terjedt el ez a tévhit? Valami igazságalapja 
kell, hogy legyen! Van is. Bizonyos alkalmazásprotokollok 
nem binárisan kódolt üzeneteket váltanak, hanem egyszerű 
szöveges parancsokkal kommunikálnak. A POP3 is jó példa 
erre, azonban az SMTP tökéletes. Ha ugyanis betelnetelnénk 
egy SMTP kiszolgálóba a 25-ös porton, akkor (nagy vonalak- 
ban) így tudnánk puszta kézzel levelet küldeni: 


-5HELO mail.netacademia.net 

£-OK 

-35MAIL FROM: marcellfénetacademia.net 
£-OK 

-3RCPT TO: akarkiésehol.com 

£-OK 

-3DATA 

.és jöhet a levél. 


A fenti utasításokkal lehet levelet küldeni mindenféle Out- 
look és egyéb úri huncutság nélkül. Mivel az SMTP a soreme- 
lést veszi a parancs végének, ennek a ,karakternek" külön- 
leges szerepe van mind az SMTP, mind a POP3, IMAP4 kom- 
munikációban - és még sok más protokollban. Tulajdonkép- 
pen minden , különleges" karakternek , különleges" szerepe 
van, mivel a fejlesztők nem igazán gondoltak sem a magyar 
nyelvre, sem a később elterjedt csatolásküldésre (virus.exe). 
Mivel a régi SMTP-t kidobni nem lehetett, a szabványfejlesz- 
tők érdekes módon vágták át a gordiuszi csomót. Minden 
olyan adat, ami nem írható le az angol ABC kis- és nagybe- 
tűivel - LEGYEN leírható az angol ABC kis-, és nagybetűivel!! 
Bölcs döntés nemde? Ezt hívják kompatibilitásnak. S lőn 
UUENCODE és MIME kódolás, melyeknek pont az a feladatuk, 
hogy a virus.exe csatolt fájlt enterekkel zárt, fix hosszúságú 
sorokból álló szöveges alakra hozzák, hogy az SMTP ne bo- 
ruljon fel tőle! Hoppá! Ipartörténeti érdekesség! 


MICROSOFT NETWORK MONITOR (IV. RÉSZ) 
Mire nem jó a TCP csatorna? 
Végezetül essen szó arról is, hogy a TCP csatorna nem min- 
denható, egyáltalán nem minden esetben érdemes használ- 
ni, sőt olyan forgalomtípusok is léteznek, melyeket képte- 
lenség csatornába zárni. Lássuk a két esetet: 
1. Nem érdemes TCP csatornát használni viszonylag kevés 
adat átvitele esetén, amikor többe kerülne a leves, mint 
a hús. Gondoljunk bele: a TCP csatorna felépítése 3 cso- 
magot igényel, s a bontás sem , olcsóbb". Ez a 6 keret az 
ára a megbízhatóságnak. De mi van akkor, ha csak egy- 
két csomagom van, melyek akár el is veszhetnek? Vagy 
még ha nem is veszhetnek el, az egyszerű megismétlés 
bőségesen elég? Gondoljunk a DNS-re: egy kérdés - egy 
válasz. Nincs szükség tördelésre, szekvenciaszámokra stb. 
Ha TCP csatornában küldenénk az egyszerű DNS lekérde- 
zéseket, két csomag helyett nyolcat kellene használni! 
2. Nem lehet TCP csatornát használni olyankor, amikor ket- 
tőnél több kommunikáló fél van, mert a TCP csatornának 
csak két vége lehet. Azaz nem csatornázunk Broadcast 
esetén, illetve multicast adatfolyam átvitelekor sem. 
Ha nem jó, vagy nem kell a TCP, akkor használunk UDP-t 
(User Datagram Protocol) , ami tulajdonképpen a TCP ,light" 
verziója. Portszámhasználat ilyenkor is van, ám nincs szek- 
venciaszám, ACK és chip-chip-choka. Viszont mivel ponto- 
san ugyanazon a programozói felületen keresztül érhető el 
(WinSock) , rendkívül kényelmesen használható. 


Fóti Marcell 
Marcellf(onetacademia.net 


Sokan megtudják mondani, hogy HOGYA 


i4e tölünk azt is megtudja, 


pnGyueg jeyeggor6aj v 
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Az MMC 


testreszabása 
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Sok cikkben olvasható az a megállapítás, hogy a Windows 
2000 Server verziójának talán egyik leghasznosabb és legiz- 
galmasabb újítása az Active Directory. A Windows NT 4.0 cím- 
tárával (NTDS — Windows NT Directory Service) összehasonlítva 
az Active Directory számos újdonságot tartalmaz. Oldalakon 
keresztül sorolhatnánk a példákat, de talán elegendő a két 
legalapvetőbb eltérést megemlíteni: a Windows 2000 címtára 
objektumokból áll, s ezek hierarchikus tárolórendszerben 
(szervezeti egységek, Organizational Units) helyezhetők el. Az 
operációs rendszer objektumként kezeli például a felhasználói 
azonosítókat, nyomtatókat, munkaállomásokat stb. Minden 
objektum számos tulajdonsággal rendelkezik, s minden objek- 
tum rá jellemző tulajdonsághalmazzal bír. A felhasználói azo- 
nosító tulajdonságai közé tartozik például a vezetéknév, ke- 
resztnév, elektronikus levelezési cím stb. Mivel a felhaszná- 
lóknak lehetőségük van tulajdonság alapján objektumokat 
megkeresni, nem szükséges megtanulniuk a hálózati erőforrá- 
sok sokszor nehezen megjegyezhető nevét. 


A Nagy Feladat 

A rendszergazdák is találhatnak sok hasznos újítást a Windows 
2000 címtárában. Nagyon sokszor előfordul, hogy többszöri té- 
ves jelszóbeírás miatt az operációs rendszer letiltja a felhaszná- 
ló azonosítóját (a felhasználó ,,kiüti" magát - a szerk.). Ilyen 
esetben a folyamatos munkavégzés biztosítása érdekében a 
rendszergazdának rövid időn belül engedélyeznie kell az azono- 
sító használatát, különben a felhasználó vagy hazamegy, vagy 
elkéri egy másik kollégájának jelszavát, és azzal dolgozik tovább 
(súlyosan veszélyeztetve ezzel az esetleg érvényben lévő naplózá- 
si rendszabályokat) . Mivel a , visszabillentés" nem tartozik a leg- 
kedveltebb rendszergazdai tevékenységek közé, ezért kézenfek- 
vő ötletnek tűnik néhány vállalkozó kedvű munkatárs megbízá- 
sa ezzel a feladattal. Már a Windows NT 4.0 operációs rendszer 
címtára is lehetőséget teremtett számunkra, hogy az általunk ki- 
választott személyeknek olyan jogosultságot adjunk, amelynek 
révén el tudnak látni bizonyos rendszergazdai feladatokat. A le- 
tiltott azonosító engedélyezéséhez például fel kell vennünk a 
szóban forgó munkatársakat az Account Operators csoportba. 
Ezzel azonban a kívántnál sokkal több jogosultságot nyújtot- 
tunk. Ugyanis az Account Operators csoport tagjai felhasználói 
azonosítókat is létre tudnak hozni, le tudnak törölni stb. Az Ac- 
tive Directory erre a problémára is kínál megoldást. A későbbiek- 
ben látni fogjuk, hogy az objektumok esetében széleskörűen le- 
lyozhatjuk, hogy egy bizonyos rendszergazdai feladattal megbí- 
zott dolgozó a kellő hozzáértés hiányában véletlenül fennaka- 
dást okozzon a számítástechnikai rendszer működésében. 


Az objektumok kezelése és a jogosultsági lista 

A Windows NT 4.0-ás környezetben a rendszergazdákat önálló, 
egymástól független programok segítették feladatuk ellátásá- 
ban (például User Manager, Server Manager stb.). Ezzel szem- 
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ben a Windows 2000 operációs rendszerben található Micro- 
soft Management Console (MMC) egységes kezelői felületet 
szolgáltat a rendszergazdai eszközök számára. Az MMC önma- 
gában nem alkalmas a rendszerkörnyezet beállításainak meg- 
változtatására, működésmódját a megfelelő snap-inek betölté- 
sével határozhatjuk meg. Például az úgynevezett Active Direc- 
tory Users and Computers snap-in révén az MMC alkalmassá vá- 
lik az Active Directoryban található számítógépes és felhasz- 
nálói objektumok kezelésére. Ez azt is jelenti, hogy - megfele- 
objektumok bármely tulajdonsága megváltoztatható. 

Minden objektum önálló jogosultsági listával (Access Control 
List — ACL) rendelkezik. Ezáltal széles körben tudjuk szabá- 
lyozni, hogy kinek biztosítunk hozzáférést az egyes objektu- 
mokhoz, illetve objektumcsoportokhoz. Az Active Directory- 
ban a jogosultságok bizonyos értelemben különböznek pél- 
dául a fájlok esetében megszokottaktól. Az objektumok ese- 
tében ugyanis nemcsak a hozzáférési szintet tudjuk szabá- 
lyozni (teljes hozzáférés, írási, olvasási jog stb.) , hanem ezen 
túlmenően az objektum egyes tulajdonságaihoz (attribútu- 
maihoz) is rendelhetünk írási, illetve olvasási jogot. A Nagy 
Feladatban említett kizárás például a felhasználóobjektumok 
hockoutTime" jellemzőjének átállítódása miatt következik 
be, s a ,visszabillentés" is ezen attribútum felülírásából áll. 
Az objektumok jogosultsági listáját a következőképpen tud- 
juk megtekinteni. Az Active Directory Users and Computers 
snap-in felhasználói felületén jelöljük ki az egyik felhaszná- 
lói azonosítót. Az objektum tulajdonságait az Action menü 
Properties parancsának segítségével tudjuk megjeleníteni. A 
párbeszédablakon a Security fül Advanced nyomógombja ré- 
vén tekinthetjük meg részletesen, hogy az objektum ACL-jé- 
ben milyen bejegyzések találhatóak. Fontos felhívni a fi- 
gyelmet arra, hogy a Security fül csak akkor jelenik meg a 
tulajdonságok között, ha a Users and Computers snap-in 
View menü Advanced Features beállítását engedélyezzük. 
Minden bejegyzés esetében a View/Edit nyomógombbal 
tudjuk megtekinteni, illetve szükség esetén megváltoztatni 
a felhasználók, illetve felhasználói csoportok az objektum- 
hoz, illetve az objektum egyes tulajdonságaihoz rendelt 
Előfordul, hogy az ACL szerkesztésekor nem látható az ob- 
jektum összes tulajdonsága. Jó példa erre a User objektum, 
amely több mint kétszázötven tulajdonsággal rendelkezik, 
így alapértelmezésben csak a fontosabbak jelennek meg - a 
mvisszabillentési" jog (lockoutTime attribútum kezelése) saj- 
nos alapértelmezésben nem! 


Hol a jog? 

Van kiút a nehéz helyzetből: minden tartományvezérlő 
9osystemroot9otsystem32 könyvtárában megtalálható a 
Dssec.dat nevű file, amely az objektumok rejtett tulajdonsá- 
gainak listáját tartalmazza. A Dssec.dat egyszerű textállo- 
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mány, így például a Notepad segítségével könnyen szer- 
keszthető. A fájlban szögletes zárójelek közé zárva találjuk 
az egyes objektumok nevét (például (user]). Ha az ezt kö- 
vető sorban a ,(2-7" bejegyzés szerepel, akkor rejtett ob- 
jektummal állunk szemben. Ez azt jelenti, hogy külön ehhez 
az objektumhoz egyáltalán nem tudunk jogosultságot adni. 
Szükség esetén úgy tudjuk az objektumot a legegyszerűbben 
megjeleníteni, hogy kitöröljük a , 2-7" bejegyzést. 

A Dssec.dat fájlban a rejtett tulajdonságok neve után is az , 77 
bejegyzés áll. Csak akkor lesznek láthatóak az ACL szerkeszté- 
sekor, ha a 7-es számot megváltoztatjuk bármilyen más érték- 
re, vagy a tulajdonság nevével együtt kitöröljük a fájlból. (Miért 
pont 7 ? — a szerk.) Ezáltal lehetőségünk nyílik, hogy ezekhez 
a tulajdonságokhoz külön-külön is jogosultságot adjunk. 


A letiltott azonosító engedélyezésének kiosztása 

A rendszergazdai feladatok, így a letiltott azonosító enge- 

délyezésének a kiosztása is két lépésből áll: 
nunk a felhasználónak vagy felhasználói csoportnak. A 
jog legyen a lehető legszűkebb, hogy a feladattal meg- 
bízott felhasználó ne tehessen kárt a címtárban. 

0 Ki kell alakítanunk a célfeladatnak megfelelő, korláto- 
zott funkciókészletű felhasználói felületet. A felhaszná- 
lói felület is legyen szűkre szabott, hogy a felhasználót 
ne zavarják meg olyan virtuális lehetőségek, amelyek- 
kel valójában nem élhet, hisz joga úgysincs hozzá. Sen- 
ki sem szereti látni az , Access denied" üzenetet! 


A jogosultságot legkézenfekvőbben a Delegation of Cont- 
rol Wizard segítségével tudjuk kiosztani. Ezen kívül azon- 
ban lehetőségünk van arra is, hogy közvetlenül az objek- 
tum ACL-jéhez adjuk hozzá az általunk kiszemelt felhasz- 
nálót vagy felhasználói csoportot. Mielőtt részletesebben 
is áttekintenénk a jogosultság-kiosztás mindkét módját, 
lehetővé kell tennünk, hogy a letiltott azonosító engedé- 
lyezéséhez a többi tulajdonságtól függetlenül is lehessen 
jogosultságot adni. A korábban leírtaknak megfelelően ezt 
úgy tudjuk megvalósítani, hogy a Dssec.dat állományból 
kitöröljük a ,lockoutTime-7" bejegyzést vagy a 7-es szá- 
mot megváltoztatjuk bármilyen más értékre. 

Most nézzük meg a Delegation of Control Wizard működé- 
sét. A varázsló az Active Directory Users and Computers 
snap-in bármely mappájának gyorsmenüjéből elérhető a 
Delegate Control parancs révén. Figyelembe kell vennünk 
csak a szóban forgó mappa alatt található objektumokra 
vonatkozik. A Delegation of Control varázslóval szervezeti 
egység, sőt tartományi szinten is tudunk jogosultságot 
kiosztani. Ez utóbbi esetben például - mivel a jogok alap- 
értelmezésben öröklődnek - a kiosztott jogosultság a tar- 
tomány összes objektumát érinti. 


Figyelem! A Delegation of Control varázsló csak hozzáadni 
tud jogosultságokat a címtár különböző pontjaihoz, töröl- 
ni és módosítani már nem képes saját korábbi outputját 
sem. Éppen ezért fontos a jogosultságállítás kézi módsze- 
reinek ismerete is - előbb-utóbb menthetetlenül szüksé- 
günk lesz erre a tudásra. 
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A Delegation of Control varázsló használatakor először meg 
kell adnunk azt a felhasználói azonosítót vagy csoportot, 
akinek, illetve amelynek jogosultságot szeretnénk adni. 
Ezt követően meg kell határoznunk, hogy mely objektum- 
telmezésben a beállításaink az adott mappában lévő összes 
objektumra érvényesek lesznek. A másik lehetőségünk, 
hogy mi jelöljük ki a megfelelő objektumcsoportot. Bárme- 
lyik megoldást választjuk is, a beállítás természetesen 
érinteni fogja a mappa újonnan létrehozott objektumait is. 
Mivel a letiltott felhasználói azonosító engedélyezéséhez 
szeretnénk jogot adni, ezért a Delegation of Control va- 
rázsló párbeszédablakán válasszuk ki a User objects mellet- 
ti jelölőnégyzetet. 


Delegation of Control Wizard Hz 21 


Active Directory Object Type 


indicate the scope of the task you want to delegate. 
Delegate control of: 

C This foldet, existing objects in this folder, and creation of new objects ín this folder 
6 Onlythe following objects in the folder. 

(Sie Link Bridge objects 

Sie Settngs objects 
(OD Stes Container objects 

IT Subnet objects 

ID Subnets Container objects 

CD Trusted Domain objects 

EJ User objects 









csmeat ] 


5 Csak a felhasználói objektumokra van szükség 





Ezzel a varázsló későbbi képernyőin megjelenő jogosultságok 
körét leszűkítettük a felhasználókon érvényesíthető jogokra. 
A továbblépést követően a hozzáférési jogosultságot határoz- 
hatjuk meg. A párbeszédablakban alapértelmezésben az álta- 
lános jogosultságok jelennek meg (General jelölőnégyzet) . Ne- 
künk viszont az egyes piciny tulajdonságokhoz, attribútumok- 
hoz tartozó jogosultságokra van szükségünk, amelyeket a Pro- 
perty-specific jelölőnégyzet kiválasztásával tudunk megjele- 
níteni. A felsorolt jogosultságok közül a ,Read lockoutTime" 
és a , Write lockoutTime" bejegyzéseket kell kijelölnünk. 

A Finish gombra kattintva a Delegation of Control varázs- 
ló aktualizálja a változtatásokat az ACL-ben. 


Ugyanez kézzel... 

Mint korábban már volt róla szó, közvetlenül a jogosultsá- 
gi listához is hozzáadhatjuk a megfelelő felhasználói azo- 
nosítót vagy csoportot. Első lépésben az Active Directory 
Users and Computers snap-in felületén jelenítsük meg pél- 
dául a Users mappa tulajdonságait (Action menü Properties 
parancs), majd kattintsunk a Security fül alján található 
Advanced nyomógombra. Ekkor megjelenik a Users mappá- 
ra vonatkozó jogosultsági beállítás. 

A párbeszédablak Add gombjával tudjuk hozzáadni a jogosult- 
sági listához azokat felhasználói azonosítókat, illetve csopor- 
tokat, amelyek még nem szerepelnek az ACL-ben. Az-ezt kö- 
vetően megjelenő párbeszédablakban határozhatjuk meg az 
egész objektumra (Object fül) vagy az objektum egyes tulaj- 
donságaira (Properies fül) vonatkozó jogokat. Az általunk ke- 
resett jogok a Properties fül alatt találhatóak, amelyek azon- 
ban csak azután jelennek meg, miután kijelöltük a megfelelő 
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objektumcsoportot. Először tehát a párbeszédablak felső har- 
madában található legördíthető listából (Apply onto) 
válasszuk ki a User objects-et, majd engedélyezzük a ,Read 


lockoutTime" és a , Write lockoutTime" jogosultságokat. 


IEZTEHTTTENTTETTET ZENET 
" Object Properties ] 
Name: [Burgundi Margit (burgundiméHypo.hu) 
Apply onto: (User objects se 


2121 


Permissions: 


Deny 





Write IP Phone Number 

ReadIP Phone Number (Others) 

Write IP Phone Number (Others) 

Read Job Title 

Write Job Title 

Read lockoutTime 

Write lockoutTime 

Read Logon Name 

Write Logon Name 

Read Logon Name (pre-windows 2000) 
Write Logon Name (pre-windows 2000) 
Read Logon NYSHKÉSÜGEB 


Hajddn ő mi cssts tis fsálkó 


TI Apply these permissions to objects and/or 
containers within this container only 





idúndoEHinnnun s 
lúúnúnünűndon 





T 
z 





o A beállított jogok öröklődnek a mappa tartalmára 


Fontos, hogy a párbeszédablak alján található jelölőnégyzetet 
(Apply these permissions to objects and/or containers within 
this container only) az alapértelmezésnek megfelelően üresen 
hagyjuk. Ellenkező esetben az újonnan beállított jogok csak a 
Users mappára lesznek érvényesek, a mappában található ob- 
jektumokra nem öröklődnek. A változtatások jóváhagyása után 
nézzük meg valamelyik felhasználói objektum jogosultsági lis- 
táját. Az öröklődés szabályainak megfelelően ezen a szinten is 
meg kell jelennie a Users mappán az imént beállított jogosult- 
ságnak. Az ACL minden bejegyzésének elején kulcsokat ábrá- 
zoló kis ikon látható. Az úgynevezett szülőobjektumtól örökölt 
jogok ikonja szürkés árnyalatú, módosíthatatlan. 


Access Control Settings for Administrator 2] 





Enterprise Admins (HY... This object only 
TA állow SYSTEM Full Control This object only 
TA állow . Prewindows 2000 Co... Special Special 
TS Allow  Administrators (HYPOC.. Special This object and all child obi. 
Ts Allow Enterprise Admins (HY... Full Control This object and all child obj, 
7 Allow . Pre.Windows 2000 Co... List Contents This object and all chid ob... 
s objects 


bee Backup ree (HY. 


meggesetati 


ha] 






ás HOSE EGE 





Tiz permission is inheted tom he patent otject and oanttdk amcess to tás obieet To stop 
inherting permissions, clear the cheekbox belov. You can edtIhe permission only atthe 
parent object where it is defined. This permission is inherted by child objects. 


[7 Allow inheritable permissions Írom parent to propagate to this object 





OK Cancel Apply 


a Az örökölt jogok szürkék, nem módosíthatók 
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A hierarchia felsőbb szintjéről származó bejegyzések csak 
akkor jelennek meg, ha az ACL beállításairól tájékoztató 
párbeszédablak alján található jelölőnégyzet (Allow inheri- 
table permissions from parent to propogate to this object) ki- 
jelölt állapotban van. Az a jogosultság tehát, amelyet a 
Users mappa szintjén osztottunk ki, csak azoknál a felhasz- 
nálói objektumoknál NEM lesz érvényes, amelyeknél az 
öröklődést szabályozó jelölőnégyzet üres. 

A jogosultság meghatározása után még egy feladatunk van: 
biztosítanunk kell a letiltott azonosítók feloldásával megbí- 
zott munkatársak számára a megfelelő(en korlátozott) fel- 
használói felületet. 


A Taskpad View és az MMC testre szabása 

A letiltott azonosító feloldásához szükséges felület biztosítá- 
sának az a legkézenfekvőbb módja, ha a felhasználó kliensé- 
re telepítjük a Windows 2000 Server rendszergazdai eszkö- 
Zeit. Az Active Directory Users and Computers snap-in azon- 
ban túl komoly eszköz erre a feladatra. A nagyszámú objek- 
tum, parancs és menü megnehezítheti a felhasználói felüle- 
ten való tájékozódást a számítástechnikában nem különöseb- 
ben képzett munkatársak számára. Szerencsére a Microsoft 
Managemet Console nagyon jól testre szabható a célfeladat- 
nak megfelelően. Ezáltal lehetővé válik, hogy csak azokat a 
funkciókat tegyük elérhetővé, amelyekre ténylegesen szük- 
ség van. A mi esetünkben a felhasználói felület nagyon egy- 
szerű lesz. A felhasználói objektumokon kívül ugyanis csak a 
letiltott azonosító feloldására szolgáló parancs elérhetőségét 
kell biztosítanunk, minden más elrejthető. 

Először is indítsuk el Microsoft Managemet Console-t 
(mmc.exe) , majd a Console menü Add/Remove snap-in pa- 
rancsának segítségével töltsük be az Active Directory Users 
and Computers snap-int. Ez a snap-in három kiterjesztéssel 
is rendelkezik (Group Policy, RAS Dialin, Terminal Services). 
Mivel ezekre a kiterjesztésekre a későbbiekben nem lesz 
szükségünk, ezért betöltésüket tiltsuk le az Extensions fül 
alatt az Add/Remove Snap-in párbeszédablakban. 


Add/Remove Snap-in E 


Standalone . Extensions l 


213] 









Use this page to enable snap-in extensions. To add a particular extension 
select the checkbox next to it. 


Snap-ins that can be extended: 


[29 Active Directory Users and Computers "] 









DÜIGroup Policy 
OZ RAS Dialin - User Node Extension 
OÖTerminal Services - Extension 


Description 








About Download 


ESET. ere 


o Ezekre a csingilingikre nincs szükségünk a Nagy 
Feladathoz 
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Ezt követően rejtsük el azokat az objektumokat, amelyek- 
kel a rendszergazdai feladattal megbízott munkatársaknak 
nem lesz dolguk. Erre szolgál a View menü Filter Options 
parancsa. A megjelenő párbeszédablakban három beállítás 
közül választhatunk. Alapértelmezésben minden objektum 
látható lesz (Show all types of objects). Ezen kívül lehető- 
ségünk van arra, hogy magunk jelöljük ki azokat az objek- 
tumtípusokat amelyeket szeretnénk megjeleníteni (Show 
only the following types of objects). Sőt egyedi lekérdezési 
feltételekkel is meghatározhatjuk a felhasználói felületen 
keresztül elérhető objektumok körét (Create custom filter) . 
Számunkra a második választási lehetőség kínál megfelelő 
megoldást, ezért kattintsunk Show only the following 
types of objects rádiógombra, és jelöljük ki a Users felirat 
mellett álló jelölőnégyzetet. Ha megnyomjuk az OK gom- 
bot, tapasztalni fogjuk, hogy csak a felhasználói azonosí- 
tók jelennek meg a snap-in felületén. 

Mivel a mi esetünkben minden felhasználói objektum a 
Users mappában található, ezért érdemes az összes többi 
mappát elrejteni. Ezt úgy tudjuk elérni, hogy a Users mappa 
kijelölése után az Action menü New Window from here pa- 
rancsára kattintunk. Ilyenkor egy új MMC ablak jön létre, 
amelyben már csak a számunkra fontos mappa található. 


Sajnos nem minden esetben alkalmazható ilyen hatékonyan 
ez a beállítási lehetőség. Például ha a felhasználói azonosítók 
szervezeti egységekben (0U) helyezkednek el, és a hierarchia 
csúcsán több OU is találnató, akkor nem így tudjuk elrejteni 
az olyan mappákat (például Computers), amelyekre nincs 
szükség, hanem - érdekes módon - a Read jog megvonásával. 
Ez azért tűnhet szokatlannak, mert szemben az NTFS-sel, ahol 
a Read jog megvonása nem tünteti ez előlünk a fájlokat és 
könyvtárakat, csak nem tudjuk azokat használni, az Active Di- 
rectoryban a Read jog , láthatási" jog is egyben! 


A felhasználói felület kialakításakor lehetőségünk van ar- 
ra, hogy a menükben szereplő parancsokhoz parancsikono- 
kat hozzunk létre. Ezáltal megkönnyíthetjük a rendszergaz- 
dai feladattal megbízott munkatársak dolgát. Parancsikont 
Taskpad View elkészítésekor hozhatunk létre. Jelöljük ki a 
Users mappát, majd az Action menü New Taskpad View pa- 
rancsával indítsuk el a varázslót. Az üdvözlő képernyő után 
meghatározhatjuk, hogy a felhasználói felületen miképpen 
jelenjenek meg az objektumok. Lehetőségünk van vízszintes 
(Horizontal list) , illetve függőleges (Vertical list) elrendezést 
választani. Mindkét esetben eldönthetjük, hogy az objektu- 
mok listája a felhasználói felület mekkora hányadát foglalja 
el (List size). Az alapértelmezett értéktől (Large) csak akkor 
érdemes eltérni, ha olyan sok ikont hozunk létre, hogy nem 
fér ki a képernyőre. A vízszintes és függőleges elrendezés 
mellett az objektumokat akár el is rejthetjük (No list). Ez 
utóbbi esetben csak az ikonok lesznek láthatóak. Az ezt kö- 
vető párbeszédablakban meghatározhatjuk, hogy a Taskpad 
View csak a kijelölt egységre (például egy bizonyos mappá- 
ra) vagy az összes, a kijelölttel azonos típusú egységre vo- 
natkozzon (például minden mappára) . Alapértelmezésben ez 
utóbbit kínálja fel a varázsló (All tree items that are the sa- 
me type as the selected tree item) , amely beállítást érdemes 
meghagyni. A következő lépésben a Taskpad View nevét kell 
megadnunk, amely közvetlenül az objektumok listája fölött 
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jelenik majd meg. Legvégül pedig a Taskpad View varázsló 
felkínálja a New Task wizard elindítását. 

A New Task varázslóval lehet az általunk kiválasztott pa- 
rancshoz gombot rendelni. Első lépésként a parancs típu- 
sát kell meghatároznunk. Mivel a gomb egy menüparancsot 
fog képviselni, ezért hagyjuk meg azt a beállítást, amit a 
varázsló alapértelmezésben felkínál (Menu command). A 
következő párbeszédablakban kell megadnunk a szóban 
forgó parancs nevét. Mivel a letiltott felhasználói azonosí- 
tó engedélyezése a Properties menüparancson keresztül ér- 
hető el, ezért a párbeszédablak jobb oldalán található lis- 
tából (Available commands) ezt az utasítást válasszuk ki. 
Mielőtt továbblépnénk, győződjünk meg arról, hogy a pár- 
beszédablak felső részén található kisablakban (Command 
source) a ,List in details pane" felirat áll-e. Ugyanis csak 
ebben az esetben fog a Properties parancs a felhasználói 
azonosítókra vonatkozni. A ,Tree item task" felirat esetén 
az ikon a kijelölt mappa vagy szervezeti egység tulajdon- 
ságait fogja megjeleníteni. 

3 


Shortcut Menu Command 
You can select a menu command Írom an item on the console tree or rom the list 
inthe details pane for that tem. 


List n detads pöne 7] 





Command source: 





JAN TasksoRteset Password. 





£2 Telntemetüser 





—eek [/ Non ]. Cse ] 





a Mire vonatkozik a parancs? Az egész fára? 


A következő lépésben a gomb nevét, ezt követően pedig a 
hozzá tartozó ikont kell meghatároznunk. Egy fontos célt nem 
tudtunk elérni sajnos a snap-in testreszabásával: a teljes Pro- 
perties párbeszédpanelt tudjuk csak odaadni a felhasználó- 
nak, amellyel szegény mégiscsak zavarba ejtően sok fülhöz, 
pipához és mezőhöz jut. Szerencsére a nyomógomb nemcsak 
menüpont aktiválására képes, hanem például VBScriptet is 
futtathatunk a segítségével, amely csendben elvégezné a 
feladatot a kijelölt objektumokon - ennek megírására most 
terjedelmi okokból nem térünk ki, ehhez hasonló teljeskörű 
címtármódosító scriptek a tavaly októberi számban részlete- 
sen szerepeltek. Az alábbi ábra szépen mutatja, hogy hányfé- 
le bemenő paraméterrel segíthetjük a script ténykedését. 
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General] Task con Command Line ] ireegét Modő Egrett Nane 
Name 
ezsikésszkőső ke 
kele —  Deszrption 
Parameters Business Phone 
SNAME-O ri ay 
Company 


Start ír 100 
a — Department 
Bun ns 


Normal window" s 


6 A bemenő paraméterek választéka script futtatása 
esetén 


Ezzel azonban még nem fejeztük be teljesen a feladatra sza- 
bott rendszergazdai eszköz elkészítését. A felhasználói 
felületet illetően ugyanis érdemes még néhány korlátozás- 
sal élnünk. Fontos lehet például a beállítások megváltozta- 
tási lehetőségének letiltása. Alapértelmezésben ugyanis az 
általunk elmentett MMC fájl Author módban fog megnyílni, 
ami lényegében azt jelenti, hogy a felhasználó minden 
beállítást meg tud változtatni. Ha az MMC Console menü 
Options parancsára kattintunk, akkor a megjelenő párbe- 
szédablakban több hasznos korlátozást is be tudunk állíta- 
ni. Először is a megnyitási módot (Console mode) állítsuk át 
rAuthor mode"-ról , User mode - limited access single win- 
dow"-ra. Ennek hatására a felhasználónak csak az MMC fájl 
elmentésekor látható ablak fog megjelenni, és új ablakokat 
sem tud létrehozni. Ezen kívül lehetőségünk van letiltani a 
jobb egérgomb lenyomásakor megjelenő gyorsmenüt (Enab- 
le context menus on taskpads in this console jelölőnégyzet) , 
a nézetek megváltoztatásának lehetőségét (Allow the user 
to customize views jelölőnégyzet), valamint megakadályoz- 
hatjuk, hogy a felhasználók elmentsék az esetleges változ- 
tatásokat (Do not save changes to this console jelölőnégy- 
zet). Sőt a felhasználói felületet tovább egyszerűsíthetjük 
a View menü Customize parancsának segítségével. Elrejthe- 
tők többek között az MMC és a snap-in menüi csakúgy, mint 
az eszközsor, az állapotsor stb. A mi esetünkben sem az 
eszközsorra, sem a menüsorra nincs szükség, ezért a meg- 
jelenítésüket érdemes letiltani. A végeredmény egy listaab- 
lak, melyben a kiemelt felhasználó kiválaszthatja pórul járt 
társát, majd rákattintva a lakat ikonra, a megjelenő Proper- 
ties ablakban kiválasztja a megfelelő jelölőnégyzetet, és el- 
végzi a rábízott Nagy Feladatot. 
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Tree Í users 7 objects (Fiter Actívated] 




















fen Users 

Name Type Description 1 
ÉZ Admiréstrátor User Bult-in account for admíri,.. 
2 Burgundi Margit User 

EB cvest User Mán ödönt för giatét aa 
2 1USRAZRA User Bult-in account for anony... 
2 Iwam AZRA User Bult-in account for Intern. 
gm User 

2 Tsintemetüser . User This user account ís used ... 











Hl ti I i TE 
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Fontos felhívni a figyelmet arra, hogy minden korlátozás 
ellenére az elmentett MMC fájlt (".MSC) a felhasználók 
meg tudják nyitni Author módban (például My Computer 
File menü Author parancs). Lehetőségük nyílik ezáltal a 
beállításaink megváltoztatására. Ez azonban nem jelenti 
azt, hogy hiábavaló volt eddigi fáradozásunk. A Windows 
2000 csoportos házirendje erre a problémára is kínál 
megoldást az Administrative TemplatestWindows Compo- 
nents Microsoft Management Console mappában található 
vRestrict the user from entering author mode" beállítás ré- 
vén. Érdemes lehet az MSC fájlt a felhasználók számára 
csak olvasható módon megosztott hálózati könyvtárba he- 
lyezni, így központi helyen, egy példányban a megváltoz- 
tatás kockázata nélkül fel tudjuk kínálni a kész , rendszer- 
gazdai" eszközöket a kijelölt felhasználóknak. 

Végezetül meg kell említeni, hogy a rendszergazdai feladat- 
tal megbízott felhasználó munkaállomására először telepí- 
teni kell a rendszergazdai eszközöket, csak ezután tudja 
majd használni az általunk elkészített MMC fájlt. Az eszkö- 
zöket a Windows 2000 Server CD 1386 könyvtárában talál- 
ható adminpak.msi segítségével tudjuk telepíteni. 


Tomasz Balázs 


balazs.tomaszohu.hypovereinsbank.com 
pszichológus 
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Használjunk 
USB-t 
és 1394-et 


Közeleg az idő, amikor PC-ink hátuljáról eltűnnek a soros és 
a párhuzamos portok csatlakozói, megszűnik a kábeláradat. 
Nem lesz PS/2-es port, nem lesz külön hangkártya- és mo- 
demkimenet, nem fog fájni a fejünk az elfogyott IRO-k 
miatt. Lesz viszont egy vagy két (néhol négy) USB konnek- 
tor, egy IEEE-1394 csatlakozó, egy monitor csatlakozó és 
egy helyi hálózati kimenet. Semmi több. 


Mi is az a(z) USB? 

Mint a neve is mutatja az USB (Universal Serial Bus) egy 
busz, melyre maximum 126 (!) eszköz csatlakoztatható. Fi- 
gyelem, ezek az eszközök összesen egyetlen egy megszakí- 
tási címet fognak elhasználni! Az eszközök bármikor csatla- 
koztathatók vagy leköthetők a buszra(-ról), az operációs 
rendszer automatikusan érzékeli és , beállítja" ezeket. Nincs 
jumperelés, nincs újraindítás, minden Plug and Play. 


Hogyan kell használni? 

Kábelezési szabályok: A kábelek legfeljebb 5 méter 
hosszúak lehetnek, melyek segítségével maximum egy 5 ká- 
belből álló láncolatot hozhatunk létre a számítógéptől a 
legutolsó még használható eszközig. (Tehát a maximális tá- 
volság a géptől 25 m, de a kábelhosszokat hiába vesszük ki- 
sebbre, a láncolat akkor is csak öt lépésből állhat.) A csomó- 
pontokban természetesen lehetnek elágazások, ha az esz- 
közök több USB porttal rendelkeznek vagy az eszköz maga 
egy USB HUB. (Így lehetséges az elméleti 126-os határ eléré- 
se.) Az alap USB kábelnek különböző a két vége, ezért le- 
hetetlen nem működő , hurkot" létrehozni. 
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a Az ábrán jól látható a maximum 5 láncszem 
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WINDOwSs 2000 


Portok? 

Egy USB port lehet aktív vagy passzív. Az aktív port maga biz- 
tosítja a rácsatlakoztatott eszköz számára az energiát (aktív 
portja természetesen olyan eszköznek lehet, amely az áramot 
nem a buszról veszi). A buszt vezérlő szoftver gondoskodik ar- 
ról, hogy ha , elfogyott a buszról az összes energia" (maximum 
500 mA) akkor több eszköz ne akarjon áramot felvenni. 
ESETET ZEEKEEEEETTT 


TÁ General Natmat töműteston . Hösdee [serto] tvamcsál 
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0 Az egérkénk passzív és sokat fogyaszt, a nyomtató vi- 
szont aktívan szerénykedik 


Ennek feloldására való az aktív port. Ha egy aktív portot tar- 
talmazó eszközt kikapcsolunk, akkor onnantól lefelé a lánc- 
ban lévő eszközök nem biztos, hogy működni fognak, minden 
az energiafelvételen múlik. Honnan tudhatjuk, hogy egy esz- 
köz mennyi energiát használ (lásd fent) vagy milyen sebes- 
séggel működik (high/low)? Erre szolgál a Windows 98 CD-n 


egy kis programocska: (tools veskitidiagnosetusbview.exe). 
aJalad 
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Az USBVIEW Windows 2000 alatt is megy... 


Az USB a következő operációs rendszerekben támogatott: 
Windows 95 0OSR2.1B; Windows 98; Windows 2000. 

És ha öregecske a gép? 

USB porttal nem rendelkező számítógépet ( pl. régebbi Pen- 
tium modellek) is bővíthetünk olyan PCI-os kártyával, amely 
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WINDOows 2000 AZ MMC TESTRESZABÁSA 


USB csatolót tartalmaz. USB segítségével akár hálózatot is 
kiépíthetünk, erre is léteznek már eszközök. 
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a Az 1.1-es USB teljes sávszélessége hamar elfogyhat 


USB 2.0 

Az USB 2.0-s verziójában (melyet olyan cégek dolgoztak ki, 
mint a Compag, HP, Intel, Lucent, Microsoft, NEC és a Phi- 
lips) a sebesség közel negyvenszeresére, azaz 480 Mbit/s- 
ra emelkedik majd! Jó hír, hogy a gyorsabb adatforgalom a 
égi" USB kábeleken zajlik, valamint a meglévő eszközök is 
ráköthetőek az új buszra (ez alól kivételek a HUB-ok, ame- 
lyek szerepét a már háromféle sebességre képes - 480, 12, 
1,5 Mbit/s - 2.0-sok veszik át). Ami viszont szükséges: egy 
USB 2.0-s PCI csatolókártya, vagy egy új alaplap, ami már 
2.0-s USB-t támogat, de sajnos ezek megjelenésére még 
várnunk kell egy pár hónapot. (Az Intel már az 1815-ös chip- 
setben ígérte a támogatást, de később ez elhalasztódott.) A 
szoftveres támogatásra is várni kell, jelenleg még nem lé- 
tezik 2.0-s USB patch a windows-okhoz. (A Whistler, ,,aka- 
rom mondani" a Windows XP már támogatni fogja.) 


Technológia Maximális sebesség (elméletben) 
Soros port 230 Kbit/s 

USB 1.1 Low 1,5 Mbit/s 

USB 1.1 High 12 Mbit/s 

FireWire 400 Mbit/s 

USB 2.0 High 480 Mbit/s 

Ultra SCSI-3 160 Mbyte/s 


Fire-Wire 

Mivel az USB 2.0 még nem elérhető, egy lehetséges alter- 
natíva lehet az IEEE 1394. Ez tulajdonképpen az Apple ál- 
tal kitalált Fire-Wire, amelynek szabványát 1990-ben kibő- 
vítették, s ennek eredményeképpen jött létre az IEEE 1394 
specifikáció. 


Sebesség 

A 1394-es busz két sebességen működhet: 200 Mbit/s-on 
(5200) és 400 Mbit/s-on (5400), ez utóbbi már 50 Mby- 
te/s-ot jelent. (Jobb, mint egy UW SCSI!) A nagy adatátvi- 
teli sebesség igénye főleg multimédiás applikációknál je- 
lentkezik, tehát azon eszközök lesznek (vannak) 1394-es 
csatlakozóval ellátva, amelyek ebben szerepet játszanak: 
camcorderek, videofelvevők, merevlemezek. Persze jelenleg 
is léteznek olyan eszközök (pl. video grabber kártyák) , me- 
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lyekkel mondjuk a videófeldogozás elvégezhető, de az 1394 
jóval olcsóbb megoldást jelent. 

Az 1394 segítségével könnyedén létrehozhatunk otthon is 
egy kis videóstúdiót, hiszen az 1394-es buszra csatlakoztatott 
videókamera és a merevlemez között közvetlen adatforgalom 
jön létre, a , film" egy szoftverrel megszerkeszthető, majd tá- 
rolható az ugyancsak a buszra csatlakozható videofelvevőn. 












































Camcorder PC 1394-es 
busszal 
Video recorder 
§ 4 Szkenner 
S ÉRT 
Nyomtató 
] J Merevlemez 











.—F—- e. 
Ezé 
o Az én kis házistúdióm... 


Kábelezés 

Az IEEE 1394-es buszra maximum 63 eszköz csatlakoztatha- 
tó egyszerre, a maximális kábelhossz (két eszköz között) 
négy és fél méter lehet. Legfeljebb 16 ilyen kábel fűzhető 
láncba, tehát a számítógép és a legmesszebb lévő eszköz ma- 
ximális távolsága 72 méter. Nincs szükség terminálásra, ID 
jumperelésre (SCSI) , az eszközök menet közben csatlakoztat- 
hatók vagy leköthetők (hot plug), minden rákapcsolt eszköz 
automatikusan címződik. Csakúgy, mint az USB esetében, a 
csillagpontos elrendezéshez HUB-okat használhatunk, de 
minden olyan eszköz, amelynek egynél több 1394-es csatla- 
kozója van már HUB-ként is funkcionál. Az eszközök áramfel- 
vétele is hasonló az USB-nél látottakhoz, azaz vannak aktív 
és passzív portok. A passzív porttal ellátott eszköz közvetle- 
nül a buszról veszi fel a működéséhez szükséges energiát, az 
aktív port pedig a passzív eszközöket tudja ellátni maximum 
3 Watt energiával. A használt kábel 6 eres: 2 kell az ,áram- 
hoz", 2 kábelen megy az adat, kettőn pedig a szinkronjel. 
(Erről többet itt most inkább nem írnék...) 


Csatlakozó 

A megfelelő csatlakozó keresésekor a következő szemponto- 
kat vették figyelembe: legyen strapabíró, legyen megfele- 
lően árnyékolt és persze olcsó! A választás a Nintendo Ga- 
meboy csatlakozójára esett... 

Azoknak sem kell elkeseredniük, akiknek a gépén nincs 
1394-es csatlakozó, hiszen vásárolható olyan kártya (álta- 
lában PCI buszos) , amely rendelkezik ilyennel. 

Végezetül csak érdekességként jegyzem meg, hogy az SCSI- 
3 specifikáció felveti az IEEE 1394 kábelek használatának 
alkalmazását is (hiszen ez jóval olcsóbb). 


Tóth László 


tothlomontana.hu 
MCSE, Compag ASE 
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A BOOT.INI 
magánélete 


Valószínűleg  UNACCESSIBLE BOOT DEVICE hibaüzenetet 
mindannyian láttak már. Ez a hiba szép kék képernyőn szokott 
megjelenni valamikor az operációs rendszer betöltésének kel- 
lős közepén. Ilyenkor hirtelen felindulásból általában elsőként 
a fejlesztők felmenőit szoktuk szidni, hogy mi az, hogy INAC- 
CESSIBLE, ha egyszer már félig bebootolt. A hiba érdekessége, 
s a sors különös fintora, hogy ebben a szent esetben nem a 
fejlesztők, és nem is Bill Gates tehet a dologról, hanem ilyen 
a gép: az Intel architektúra egy szörnyű korlátjába ütköztünk. 
Mert legyen bár az INACCESSIBLE lemez SCSI vagy IDE, min- 
denképpen a BIOS okolható a rendszertöltés meghiúsulá- 
sáért. Vagy azért, mert nincs is (például le va tiltva a SCSI 
vezérlőn) , vagy azért, mert pont olyan helyről akarunk boo- 
tolni, amit a BIOS már nem , lát". Köztudott talán, hogy a 
BIOS-ok maximum 7,8 gigabájtot képesek kezelni a legna- 
gyobb merevlemezekből is, ennél többet akkor sem látnak, 
ha márkás gyártó BIOS-ával állunk szemben. Most nem ve- 
zetném le bitszintig, hogy miért pont 7,8 giga az ,álomha- 
tár", hisz tavaly ezt egyszer már megtettem. 

Tehát a probléma gyökere abban keresendő, hogy bár a booto- 
lás elindulhatott a BIOS segítségével (hisz másképp nem tud 
elindulni) , ám befejeződni már nem tudott: egyszer csak kikerült 
az éppen betöltendő rendszerkomponens a gép látómezejéből. 
Egy paradoxont hadd oldjak fel mindjárt. Persze, hogy a 
Windows 2000 tetszőleges nagyságú (sajnos ez max. 2 tera- 
bájt Intelen, s nem 16 exa, ahogy a prospektus mondja) par- 
tíciót tud kezelni, de ahhoz nem is a BIOS INT 13 megsza- 
kításaival fér hozzá, hanem közvetlenül, saját eszközmeg- 
hajtójával, melynek neve IDE esetén ATAPI.SYS. 

Eddig azonban el kell jutni! A rendszertöltés igenis mindig 
BIOS-sal indul, hisz az minden gépen mindig elérhető, s 
csak az oprendszer betöltésének egy későbbi fázisában le- 
het tőle megszabadulni. Ha azonban ez a váltás, staféta- 
átadás valami miatt meghiúsul, akkor egy félig kész op- 
rendszert , nyerünk", ami ennyire képes: 
INACCESSIBLE BOOT DEVICE. 

A rendszertöltés folyamatának teljes megértéséhez rendha- 
gyó, de lehet, hogy hagyományteremtő eszközhöz nyúltam: 
animációt készítettem (PPT)! Az alábbi ábra ennek csontvá- 
zát mutatja, de ennél lényegesen szebb, kommentált remek- 
művel van dolgunk, amely az [1] címről tölthető le. 
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WINDOWS 2 


Az ominózus kék képernyős hiba akkor következik be, ami- 
kor az NTLDR (ez már NT!) megpróbálja megkeresni a boot 
partíciót, tehát az NTOSKRNL.EXE-t tartalmazó lemezterü- 
letet. A probléma teljes elkerülésének módja az lehetne, ha 
a BIOS-tól a lehető legkorábbi pillanatban meg lehetne 
szabadulni, azaz már az NTOSKRNL.EXE megtalálásához sem 
kellene BIOS (ennél korábbi fázisban nem lehet lerázni a 
BIOS láncait!). Van rá mód! Ugyanis az ábrán látható 
NTLDR is képes lehet saját eszközmeghajtó használatára, 
ha teljesítjük összes kívánságát: 

1. Az eszközmeghajtó az aktív partíció gyökerében legyen 
2. Neve legyen szigorúan NTBOOTDD.SYS 

3. A BOOT.INI-ben pedig ne MULTI(), hanem SCSI() szerepeljen. 
A harmadik kívánság kicsit abszurd nem? Ha a merevleme- 
zem IDE, akkor ugyebár nem SCSI, és vica versa. 


Amit tudni akartál a BOOT.INI-ről, de nem merted meg- 
kérdezni 

A teljes igazság így hangzik: 

"0 A MULTI() nem azt jelenti, hogy a merevlemez IDE, ha- 
nem azt, hogy BIOS INT 13 megszakítással kezelendő. 
SCSI lemezekről is elstartol, ha a kártyán engedélyezve 
van a BIOS. 

A SCSI() nem azt jelenti, hogy SCSI a lemez, hanem 
hogy saját eszközmeghajtóval kezelendő. És IDE leme- 
zekkel is használható, ha a BIOS-t kiváltjuk a megfele- 
lő eszközmeghajtó programmal. 

Ez mindent megmagyaráz. Éppen olyan megkövült termino- 
lógiai bakival állunk szemben, mint amilyen például a 
SYSTEM és a BOOT partíció megnevezése a Windows 2000 
dokumentációban, ugyanis a SYSTEM partíció arról ismerhe- 
tő fel, hogy azon vannak a BOOT fájlok, míg a BOOT partí- 
ción találjuk a WINNT könyvtárat, tehát a SYSTEM-et :-0 
Ezzel a tudással felvértezve mindenki elvégezhet egy érde- 
kes kísérletet a saját asztali, SCSI-t sosem látott gépén. 
Érintetlenül hagyva a meglévő BOOT.INI bejegyzéseket (hogy 
legyen legalább egy ép menüpontunk a hekkelés után), készít- 
het egy újat, ami SCSI() kezdetű! Ha a három fenti feltétel 
teljesül, a Windows 2000 tökéletesen bebootol az NTBOOT- 
DD.SYS meghajtó segítségével. S hogy honnan szdjük az 
NTBOOTDD.SYS-t? Nos - hogy minden kíváncsit a webre terel- 
jek - az [1] címen található kiváló PPT utolsó előtti lapján 
olvasható a titok megfejtése. Vigyázat, másképp kell előállí- 
tani a fájlt Windows NT 4.0 és Windows 2000 esetén! 


Fóti Marcell 
marcellfonetacademia.net 


A cikkben található URL-ek: 
t 


t/bootini.. 


technet.netacademia.net/feladatok, 


[1] http: 
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Az üzlet gyakran zavarosabb életünk bármely más területé- 
nél. Általánossá vált a cégek gyakori átszervezése, ami a szá- 
mítástechnikai részleg fő gondjává válhat, hiszen többnyire 
együtt jár a számítógépek áthelyezésével és néha a teljes 
tartománymodell átszervezését jelentheti. Bonyolultsága 
miatt az Exchange Server 5.5 azok közé az összetevők közé 
tartozik, amelyeket a legnehezebb átszervezni. Utódját, az 
Exchenge Server 2000-t lényegesen könnyebb, de a meglévő 
régi rendszerek nagy száma miatt talán mégsem érdektelen 
szót ejteni a Moveserver.exe-ről, mely lehetővé teszi a moz- 
díthatatlannak hitt Exchange 5.5 kiszolgáló újratelepítés 
nélküli áthelyezését más telephelyre (site), illetve szervezet- 
be (organization). Ez a cikk megpróbálja megkönnyíteni az 
informatikusok munkáját és bemutatja, hogyan helyezzük át 
egyik telephelyről a másikra az Exchange Servert. 


Tervezés 

A sikeres áthelyezés kulcsa a körültekintő tervezés. Az át- 
helyezéshez használt segédprogram kezelése viszonylag 
egyszerű és tesztjeink során semmiféle probléma nem me- 
rült fel az Inbox, a Calendar, a Contact Manager, a Task List 
és a többi összetevő áthelyezésénél. Mindazonáltal az áthe- 
lyezést végzőnek sok a tennivalója. 


Mentés 

Amikor kiszolgálókat helyezünk át, mindig fennáll annak a 
veszélye, hogy valami nem sikerül. Mielőtt hozzákezdünk, 
mindig készítsünk mentést minden egyes kiszolgálón, ami- 
vel dolgozunk. 


Az Exchange ügyfelek előkészítése 

Mielőtt áthelyezzük a kiszolgálót, meg kell értenünk, hogyan 
befolyásolja az áthelyezés az ügyfeleket. Általában semmit 
nem kell változtatnunk az ügyfélen, mert nem változik a ki- 
szolgáló neve. Mint ismeretes, az Exchange Client és az Out- 
look a kiszolgáló nevét használják a kapcsolódáshoz, nem a 
telephely nevét. Ennek ellenére bizonyos esetekben szüksé- 
gessé válhat az ügyfél újrakapcsolódása a megfelelő postalá- 
dához. Különösen igaz ez akkor, ha azon a telephelyen, aho- 
va a kiszolgálót áthelyezzük, már van egy másik kiszolgálón 
ugyanolyan nevű postaláda. Ha a kiszolgálót más tartomány- 
ba akarjuk áthelyezni, mint amibe az ügyfelek bejelentkez- 
nek, meg kell győződnünk arról, hogy léteznek a megfelelő 
megbízotti kapcsolatok (trust relationships) . 


E-mail-címek 

Fontos kitérni arra, hogy mi történik azokkal az e-mailek- 
kel, amelyek egy áthelyezett postaládába érkeznek. A belső 
üzenetek nem változnak, mert minden, az áthelyezéssel 
kapcsolatos változás automatikusan bekerül a globális cím- 
listába (feltéve, hogy a replikáció működik) . 


A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
2001. 053. 


Exchande 
atszervezes 


Az internetes üzenetekkel más a helyzet. Mint tudjuk, a ki- 
szolgáló IP-címe a DNS-kiszolgáló listáján a kiszolgáló do- 
main nevével együtt áll. A kiszolgáló áthelyezésekor min- 
den postaláda megtartja eredeti SMTP-címét. Mivel a kiszol- 
gáló neve és IP-címe megmaradt, és mivel van DNS-hivat- 
kozás a kiszolgálóra, az eredeti címnek továbbra is működ- 
nie kell. Minden postaládához egy új SMTP-cím is hozzá van 
rendelve, ami megfelel a hídfő kiszolgáló DNS-bejegyzésé- 
nek. Ennek a címnek is működnie kell. 


A kiszolgálók előkészítése 

Miután megterveztük az áthelyezést, elő kell készítenünk a 
kiszolgálókat. Győződjünk meg arról, hogy mindkét oldalon 
Exchange 5.5 fut (legalább 2-es szervizcsomaggal) . Az eljá- 
rás nem működik az Exchange régebbi verzióival vagy 1-es 
szervizcsomaggal." 

Miután ellenőriztük az Exchange verziószámát, engedélyez- 
nünk kell a telephelyek közötti címtárreplikációt. Ez azt je- 
lenti, hogy mindkét telephely tud egymásról és közös glo- 
bális címlistájuk van. Ehhez létre kell hoznunk egy telep- 
helycsatolót (Site Connector) és egy címtárreplikációs csa- 
tolót (Directory Replication Connector). 


A Site Connector (telephelycsatoló) beállítása 

A Site Connector feladata, hogy logikai hivatkozást hozzon 
létre a két telephely között. A Site Connector beállítása előtt 
már léteznie kell fizikai összeköttetésnek. Az összekapcsolan- 
dó telephelyeknek ugyanabban a szervezetben kell lenniük. 
Figyeljünk arra, hogy a szervezetnevek esetében nem mind- 
egy, kis- vagy nagybetűt használunk-e. A Site Connector lét- 
rehozásához jelöljük ki a ,Connections" menü New Other ] Si- 
te Connector pontját és adjuk meg a megfelelő információkat. 


A Site Connector beállítása a legtöbb esetben egyszerű és 
világos. Mégis hangsúlyoznunk kell egy bizonyos lépést, 
amelyen sok minden múlhat. Az Exchange telepítésekor a 
telepítő program kérte, hogy adjunk meg egy bejelentkezé- 
si nevet - melynek jogaival az Exchange futni fog - és a 
hozzá tartozó jelszót. Az Exchange ezt a bejelentkezési ne- 
vet arra használja, hogy kommunikáljon a Windows NT-vel. 
Ennek eredményeképpen mindkét telephelynek tudnia kell 
a másik bejelentkezési nevét és jelszavát. Ezeket az infor- 
mációkat a Site Connector , Properties" lapján az , Override" 
fülön lehet megadni. Ne feledjük, hogy ha a két telephely 
hídfő kiszolgálója különböző Windows NT tartományokban 
található, akkor a Site Connectornak kétirányú megbízotti 
kapcsolatot kell megadni a tartományok között. 


tech.net! 


A Directory Replication Connector (címtárreplikációs 
csatoló) beállítása 

A Site Connector létrehozása után be kell állítanunk a 
Directory Replication Connectort. A Directory Replication 
Connector létrehozásához válasszuk ki a Directory Replica- 
tion tárolót, majd a , File" menü New Other ] Directory Rep- 
lication Connector pontját. 

A Directory Replication Connector beállítása egyszerű, csu- 
pán meg kell adnunk az adatokat a , Directory Replication 
Connector Properties" adatlapon. Az egyetlen, amire fi- 
gyelnünk kell, hogy ugyanúgy, mint a Site Connector ese- 
tében, itt is mindkét telephelyen be kell állítanunk a rep- 
likációs csatolót. A beállításnál a ,Schedule" fülön mind- 
két telephelyen , Always"-et kell kijelölni. Ne törődjünk ve- 
le, ha a ,Sites" fülön semmi nem látszik. Később, a repli- 
káció kezdetekor ez az információ is automatikusan meg- 
jelenik. Onnan tudhatjuk, hogy a replikáció befejeződött, 
hogy az Exchange Administratorban mindkét telephely lát- 
szik, mint azt az alábbi ábra mutatja. 
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Delete" gombot. Ekkor figyelmeztető üzenet jelenik meg, 
kattintsunk a ,Yes" gombra a folytatáshoz. Ezután az 
Exchange megkérdezi, akarjuk-e a másik telephelyről is tö- 
rölni a Directory Replication Connectort. Kattintsunk a 
Yes" gombra és az Exchange törli a Directory Replication 
Connectort. Kattintsunk az , OK" gombra, majd tegyük ezt 
újra, hogy átlépjünk a figyelmeztető üzeneten. 

Ha eltávolítottuk a Directory Replication Connectort, töröl- 
nünk kell a telephelyeket összekötő csatolót (Site Connec- 
tor) is. Ehhez az Organization ] site ] Configuration ] 
Connections konténerben jelöljük ki a Site Connectort és 
nyomjuk meg a , Delete" gombot. Amikor a program meg- 
kérdezi, akarjuk-e törölni a Site Connectort, kattintsunk a 
Yes" gombra. A Site Connectort a másik telephelyen is 
ugyanígy törölnünk kell. 

A Site Connector eltávolítása után eltűnik a másik telephely, 
amint az az alábbi ábrán látható. Ez akár egy órát is igény- 
be vehet. Az F5 gombbal frissíthetjük az Exchange Administ- 
rator nézetét, hogy lássuk, eltűnt-e már a másik telephely. 
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Az áthelyezés végrehajtása 


Ha egy kiszolgálót másik telephelyre akarunk áthelyezni, el- 
ső lépésként ki kell csomagolnunk a Move Server segédprog- 
ramot. Helyezzük az Exchange 5.5 2-es szervizcsomagjának 
CD-jét a CD-meghajtóba. Hozzunk létre egy Movesrvr 
nevű könyvtárat a merevlemezen és másoljuk bele a CD 
MservertEngtServertSupport Movesrvr. könyvtárának tartal- 
mát. Ezután indítsuk el a Setupmvi.exe fájlt. Ha a kicsoma- 
goló program megkérdezi, hova akarjuk tenni a fájlokat, ad- 
juk meg neki a merevlemezen található Movesrvr könyvtárat. 


Az Exchange Server elválasztása 

Mielőtt használhatnánk a Move Server programot, el kell vá- 
lasztanunk az Exchange Servert. Ehhez meg kell szüntetnünk 
a két telephely között az imént létrehozott címtárreplikáci- 
ós csatolót, hisz arra már nincs szükség. Kérdezhetnénk, 
hogy miért hoztuk létre, ha máris megszüntetjük, de tapasz- 
talataink szerint a telephelyeknek legalább egyszer tudniuk 
kellett egymásról, különben az áthelyezés nem sikerül. 

A Directory Replication Connector eltávolításához keressük 
meg az Exchange Administratorban az Organization ] Site 
] Configuration ] Directory Replication tárolót. Jelöljük ki 
a Directory Replication Connectort majd nyomjuk meg a 
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a A távoli telephelyek végül eltűnnek az Exchange Ad- 
ministratorból. 


A következő lépésben ellenőriznünk kell, hogy azon a ki- 
szolgálón, amit át akarunk helyezni, fut-e a Microsoft 
Exchange Event Service. Ha igen, el kell távolítanunk. Eh- 
hez indítsuk el a Microsoft Exchange Server Setup progra- 
mot és válasszuk az Add/Remove Components menüpon- 
tot. Ha az alábbi ábrán látható párbeszédpanel megjelenik, 
jelöljük ki a Microsoft Exchange Server sort és kattintsunk 
a ,Change Option" gombra. Ekkor megjelenik a Microsoft 
Exchange Event Service. Távolítsuk el az ,Event Service" 
kijelölését és kattintsunk az , OK" gombra a folytatáshoz. 
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Inthe Options (ist, select items you want installed; clear items you do not want installed. 
If you want to install only part of the selected option, choose Change Option. 























Options 
[Mierosoít Exchange Server 5782K] 
[4] Microsoft Exchange Administrator 32K 
Books Onine 53568K 
Outlook Web Access 14048K 





F Directory for Currenty Selected Option —— 

















CNEXCHSRVA 
Space Regúred on C- 5I84K — Componentsto addt o 
Space Avalable on C: 395488K — Components to remove: 1 





Lese] ( crea [7 He ] 


o Használjuk a Microsoft Exchange Server Setup progra- 
mot az Exchange Event Service eltávolításához. 


A Move Server Wizard használata 

Elérkeztünk a tényleges áthelyezéshez. Nyissuk meg a 
MovesrvriWvexsrvr.exe fájlt, ami elindítja a Microsoft 
Exchange Move Server Wizardot. Kövessük az utasításokat, 
amíg a következő ábrán látható ablakhoz érünk. Vegyük fi- 
gyelembe a kijelzett helyigényt. Ezek a becslések nem min- 
dig pontosak, ezért olyan meghajtót válasszunk, ahol sok 
szabad hely van. Ha áthelyezés közben elfogy a szabad 
hely, az beláthatatlan következményekkel járhat. 











Microsoft Exchange Move Server Wizard 


Location of Fies on the TÁLAINIA" Server 
Confimtha locaton of tempora fiez csalad the Move Server Wizard. Ako, the wizard ve 
"modily the Exchange Directory and Pirvate Information Store. 





Iempoy Fe SEVBEHE Browse... 
Piivate Information Store. [DAEZCHSAVRIMOBDATATPRIV.EDB 


Exchange Directory: . [D.SEXCHSRVRIOSADATAWDIR.EDB 


Space reguired on díive C. 11M8. 
Space reguired on díive D: 23MB. 


Space avalable on diííve C: 386MB. 
Space avalable on díive D: 138948. 
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5 Olyan meghajtót válasszunk, amelyen sok szabad hely 
van. 


Ha kijelöltük a használni kívánt merevlemezeket, kattint- 
sunk a , Next" gombra a folytatáshoz. Ekkor egy olyan ab- 
lak jelenik meg, amely hasonlít a Microsoft Exchange Ser- 
ver Setup programjában látottra. Mivel éppen azon va- 
gyunk, hogy egy kiszolgálót egy másik telephely részévé te- 
gyünk, kiválasztjuk a ,Join an existing site" lehetőséget, 
megadjuk a szükséges információt, mint azt a következő 
ábra mutatja, majd a ,Next" gombra kattintunk. 
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Microsoft Exchange Move Server Wizard 


Select Move Method for the "TALAINIA" Server 
Select whether to join an esősting síte or create a new site. 


G Jon an existing se 


jelk Szellő elet KáZeNÉ E ERO SANTOS NA KS KETBSO] 
/ se. Typeinthe name of an existing server in the. se. 








ara [TEST tr [18 


5 Adjuk meg a kiszolgáló nevét azon a telephelyen, aho- 
vá csatlakozni akarunk 





Ezután megjelenik egy ablak, amelyben meg kell erősítenünk 
az imént megadott információkat. Amennyiben az informá- 
ciók helyesek, kattintsunk a ,Yes" gombra a folytatáshoz. 
Ekkor egy figyelmeztetést látunk, amely felhívja a figyelmet 
arra, hogy az a telephely, ahova a kiszolgálót át akarjuk he- 
lyezni, ugyanannak a szervezetnek a része és a két telep- 
hely között nem replikáljuk a címtárinformációkat. Kattint- 
sunk a , Yes" gombra és folytassuk az áthelyezést. 

A varázsló ezután kéri az új telephely szolgáltatásfiókjának 
(service account) bejelentkezési nevét és jelszavát. Az in- 
formációk megadása után kattintsunk a ,Next" gombra. 
Győződjünk meg róla, hogy a ,Move All Custom Recipients 
From This Site" jelölőnégyzet ki van jelölve és kattintsunk a 
vNext" gombra. A következő ablakban a varázsló megkérde- 
zi, hogyan kezelje a levelezési listákat. Ha nincs semmilyen 
különösebb óhajunk, jelöijük ki a ,Move ALL Distribution 
Lists In The Site" sort, majd kattintsunk a , Next" gombra. 
A lent bemutatott képernyő jelenik meg előttünk. Mivel 
minden postaládának van már Windows NT fiókja, itt sem- 
mit nem kell tennünk, kattintsunk egyszerűen a , Next" 
gombra. Ha más tartományt adunk meg, akkor a létező fió- 
kok nem tudják elérni a hozzájuk tartozó postaládákat. Ha 
a ,Next" gombra kattintunk, a program elkezdi keresni az 
áthelyezendő objektumokat. 


Microsoft Exchange Move Server Wizard 


Update Primary Windows NT Servet User Accountr 
Essen áte ea Ea rsals sert el ször 
"moving with the "TALAINIA" server. 


meset sá ez ga] 
an name. 











0 Ne változtassuk meg a Windows NT tartományokat 
ebben az ablakban, hacsak nincs rá különleges okunk. 
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A varázsló ebben a szakaszban lehetővé teszi, hogy átne- 
vezzük a már létező objektumokat és ellenőrzi, hogy min- 
den készen áll-e mindkét kiszolgálón, közben tájékoztat 
bennünket, mit tesz éppen. Ha készen állunk az áthelyezés- 
re, kattintsunk a , Finish", majd az ,I Understand" gombra. 
Az áthelyezés sokáig tarthat, különösen akkor, ha a kiszol- 
gálón sok a felhasználó. Itt látható, hogy a varázsló kijel- 
zi, hol tart a folyamat, így végigkövethetjük: 


Microsoft Exchange Move Server Wizard 


Moving Exchange Server 


Preparing to move the server 

Instaling the new dírectory database 

Importing recipient containers 

Importing mailboxes 

Importing custom recipients 

Importing díistibution Ésts 

Importing configuration information 

Importing dírectory nk s 

Generating new e-mai addresses 

Updating messages in the private information store 
Performing cleanup operations in the original site 
Performing cleanup operations in the destination síte 
Estimated Time to Complete: 0-01:05 
Estimated Completion Time: — 2/12/99 1:24 PM 


Shulting down Exchange Services 


2096 





0 Ebben az ablakban végigkövethetjük az áthelyezés 
folyamatát. 
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Amikor az áthelyezés befejeződött, kattintsunk a 
aFinished" gombra. Ha megnyitjuk az Exchange Administra- 
tort, a kiszolgálót annak a telephelynek tagjaként kell lát- 
nunk, ahova áthelyeztük. 


§a Microsoft Exchange Administrator - [Server TITANIUM in Site BUD - TITANIUMI 


ly Bia BORT vise Ero TVnet E HRGJETEZT 
TITANIUM ef HÜ z tglizl a 3] ca xI. 


B Posey Enterpiises 1 
EH Address Book Views 










a (EA Folders SZ Protocols 
31 Global Address List EJ Public Information Store 
9 BUD § Server Recipient: 
7 Gy Configuration áj Directory Synchronization 
(8 Addin: EL Message Transfer Agent 


a HG Addressing 
2 Connection: 
Új Directory Replication 
(A) Monitor: 
ASZ Protocols 
za gy Server 
3] TALAINIA 
2 3 MITANIUMI 
££2 Recipient: 


a System Altendant 
(Ld TITANIUM DS 





5 A kiszolgálónak most már az új telephelyen kell meg- 
jelennie. 


Végkövetkeztetés 

Ebben a cikkben bemutattuk, hogyan lehet áthelyezni az 
Exchange kiszolgálót egyik telephelyről a másikra. Feltét- 
lenül tartsuk szem előtt, hogy ezt a feladatot úgy lehet a 
leggördülékenyebben véghezvinni, ha kivitelezését megfe- 
lelő tervezés előzi meg. 


64 és 128 Kbit/sec-os 
Bérelt vonalak 


a távközlési szol 


v-belépési díj nélkül 
vrouter biztosításával 


v"webszerver működtetésével 


v ajándék telefonos interneteléréssel 
v1 db .hu és 1 db .com domainnév za 


VDNS szerviz biztosítással 


áraink ÁFA nélkül és 2001. április 30-ig érvényesek. 
n a 06-40-HUNNET telefonszámon vagy info-dahol.com címen! 


tech. net! 
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Mobile 


Information Server 


Óvatos becslések szerint 2002-re 6-800 millió internetezésre al- 
kalmas mobiltelefon lesz használatban világszerte. A vállalatok 
szeretnék, hogy alkalmazottaik bárhol és bármikor elérjék a 
fontos adatokat, a fogyasztói igények pedig a nagysebességű 
vezeték nélküli hálózatok irányába terelik a fejlesztéseket. Az 
alkalmazottak gyakran dolgoznak útközben és otthonról, ezért 
szükségük van a vállalati hálózat mobil eszközről történő eléré- 
sére, hiszen így tudnak megalapozott döntéseket hozni, haté- 
konyan kiszolgálni a vásárlókat és folyamatosan követni az iro- 
dában történteket. A mobileszközök terjedésével egyidejűleg 
azonban szükség lesz arra is, hogy ugyanúgy képesek legyenek 
megóvni a vállalat adatainak integritását és titkosságát, mint 
manapság a vezetékes eszközökkel, ezért minden, a vállalati 
intranetet bővítő mobileszköznek meg kell felelnie a következő 
feltételeknek: 

"0 A felhasználói azonosítók és jelszavak ne legyenek ,le- 

hallgathatók" 

"0 Biztosítható legyen a vállalati adatok bizalmas kezelése 
-0 Tartható legyen az alacsony birtoklási költség (TCO) 


A Microsoft Mobile Information 2001 Server Enterprise Edi- 
tion és a Microsoft Mobile Information 2001 Server Carrier 
Edition újfajta mobilalkalmazás-kiszolgálók, melyeket úgy 
terveztek, hogy megfeleljenek a vállalatok biztonsági elvá- 
rásainak. Ezek a kiszolgálók biztosítják a felhasználóknak a 
vállalat adatainak (például intranet és Exchange) mobil 
elérését. A Mobile Information Server együttműködik a je- 
lenlegi mobileszközökkel is, de teljes funkcionalitása csak az 
új generációs, fejlettebb ketyerékkel lesz kihasználható. Je- 
lenlegi változata csak a WAP-os telefonok használatát támo- 
gatja, de a későbbi változatokban és külső gyártók kiegészí- 
tői segítségével támogatott lesz a WAP mellett a HTML, és 
az intelligens telefonok, digitális személyi asszisztensek 
(PDA-K) , kétirányú személyi hívók használata is. 

A Windows támogatja a szabványos biztonsági protokollok 
használatát (a Microsoftnak jelentős szerepe volt abban, hogy 
a vállalati (vezetékes) hálózatokban végponttól-végpontig biz- 
tonságos adatátvitel legyen megvalósítható, például a Point- 
to-Point Tunneling Protocol (PPTP) és az Internet Security Pro- 
tocol (IPSec) segítségével) . Ebben a cikkben azt mutatjuk be, 
hogyan valósít meg a Microsoft ehhez hasonló biztonsági 
funkcionalitást a Mobile Information 2001 Server-ben. 


Miért is más a , vezeték nélküli"? 

A vezeték nélküli átvitel biztonságossá tétele természeté- 
ből adódóan igen bonyolult lehet. Amikor egy ilyen modem 
jeleket visz át, gyakorlatilag bárki elcsípheti az adást. A di- 
gitális mobiltelefon rendszerek elterjedése előtt virágzott a 
telefonhamisítás. Ehhez csak egy adóvevőre és néhány ol- 
csó dekódoló eszközre volt szükség, és már hozzá is lehe- 
tett férni bárki telefonszámához. A digitális vezeték nélkü- 
li hálózatok jobb védelmet nyújtanak, de mivel maga a hor- 
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dozó közeg fizikailag nem biztonságos, mindenképp haté- 
kony adatvédelemre van szükség. 
A vezeték nélküli hálózatok lassabbak, hajlamosabbak az 
átviteli hibákra, és késleltetésük is nagyobb, mint vezeté- 
kes társaiké. Ebből adódik, hogy a vezetékes hálózatokhoz 
tervezett megoldásokat nem lehet egy az egyben vezeték 
nélküli hálózatokban alkalmazni. Például nem mindegyik 
vezeték nélküli hálózat támogatja a szabványos Internetes 
protokollok, így például a Transmission Control Protocol 
(TCP) használatát. E problémák enyhítésére a legnagyobb 
gyártók új protokollokat fejlesztenek, és olyan új megoldá- 
sokat hoznak létre, amelyekben a vezeték nélküli és veze- 
tékes hálózatok közti átjárás biztosítására váltókiszolgálók 
működnek. A Wireless Application Protocol (WAP) Forum, 
amelynek a Microsoft is tagja, bemutatott egy protokollcso- 
magot, melyet a vezeték nélküli hálózatokra optimalizáltak, 
és kiegészíti a meglevő szabványos Internetes protokollo- 
kat. A vezeték nélküli és vezetékes hálózatok közti átmenet 
biztosításához a Mobile Information Server protokollátala- 
kítókat tartalmaz, vásárlói pedig egy funkciókban gazdag és 
integrált átjárót kapnak. 
A vezetékes és vezeték nélküli hálózatok közötti kiszolgáló 
vezeték nélküli protokollokat és biztonsági szabályokat biz- 
tosít a kommunikáció vezeték nélküli részéhez, míg hagyo- 
mányos protokollokat és biztonsági szabályokat a vezetékes 
részhez. Ezeket a szolgáltatásokat nyújthatja egyetlen, de 
akár több felügyeleti tartományhoz tartozó kiszolgáló is. A 
mai vezeték nélküli környezetekben például egy - a vezeték 
nélküli eszközökhöz adatot szállító - WAP kiszolgálót, és egy 
Mobile Information Server-t futtató számítógépet jelenthet, 
amely átjárást biztosít a cég intranete felé. Az ilyen típusú 
hálózatokban a kommunikációnak több szakasza van: 
"0 A vezeték nélküli eszköztől a WAP kiszolgálóig 
"B A WAP kiszolgálótól a Mobile Information Server-ig 
b A Microsoft Mobile Information Server-től a háttér-ki- 
szolgálókig (például Exchange, IIS és SOL Server). 


A következő részben ismertetjük, hogy hogyan is biztosítja a 
Mobile Information Server ezeken a szakaszokon a kommuni- 
káció biztonságosságát. 


A Mobile Information Server biztonsága 

A Microsoft célja az, hogy a vezetékes hálózatokban megszo- 
kott biztonsági funkciók rendelkezésre álljanak a vezeték 
nélküli megoldásoknál is. A köztes kiszolgáló, azaz a vezeté- 
befolyásolhatja a hitelesítést és az adatok titkosságát. A mai 
WAP-os telefonok nem támogatják a fejlett hitelesítési és 
titkosítási (például SSL) eljárások használatát, ezért a 
Mobile Information Server első verziója alap (basic) hitelesí- 
tést és szakaszonkénti titkosítást használ. A külső megoldás- 
szállítók és a Mobile Information Server későbbi változatai - 
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amint az erre alkalmas telefonok megjelennek - valószínűleg 
további hitelesítési eljárásokat is támogatni fognak (például 
a Digest Authenticationt és az ügyfélbizonyítványokat) . 

Az alábbi ábrán egy tipikus, Mobile Information Server-t 
tartalmazó hálózat látható, melyen külön ki vannak emel- 
ve a titkosítás szakaszai. A Mobile Information Server a két 
tűzfal közti demilitarizált zónában (DMZ) található. Ez az 
elhelyezés fokozza a biztonságot, mert a külső tűzfal a kí- 
vülről nyitott kapcsolatok közül csak a DMZ-ben levő ki- 
szolgálók felé irányulókat engedélyezi, a belső tűzfal pedig 
csak a DMZ-ben levő kiszolgálók és a háttérkiszolgálók köz- 
ti kapcsolatokat teszi lehetővé. Ily módon a mobil ügyfe- 
lek sosem kapcsolódnak közvetlenül a vállalat belső kiszol- 
gálóihoz. (Egyszerűbb esetben a DMZ a tűzfal harmadik ,,lá- 
ba". Természetesen a fenti megoldás így is működőképes, a 
két tűzfalas megoldás viszont szemléletesebb. ) 











1 Exchange 
Carrier 
SSL Vállalat 2000 Server 
titkosítás 
I Internet 
WTLS ! , 
itkosíi WAP Mobile Information Active 

titkosítás 7 ssziszőő tn Aetive 


l 
VPN és IPSec 


5 A Mobile Information Server, és a titkosítás szakaszai. 


Mindegyik szakaszban más biztonsági eljárást alkalmazunk: 
"0 A WAP eszköz és a WAP kiszolgáló között az azonosí- 
tók a Wireless Transport Layer Security-val (WTLS) van- 
nak titkosítva. Ez egy vezeték nélküli biztonsági és tit- 
kosító protokoll, melyet a WAP Forum fejlesztett ki. A 
WAP-os telefonok támogatják ennek használatát. 

A WAP kiszolgáló és a Mobile Information Server között 
a felhasználói azonosítók SSL-lel vannak titkosítva. Az 
SSL nyílt kulcsú és szimmetrikus kulcsú titkosítás kom- 
binációját használja arra, hogy biztonságos kapcsola- 
tot építsen ki egy a WAP kiszolgáló és a Mobile Infor- 
mation Server között, és az adatok átvitele előtt titko- 
sítsa azokat. Az Internet szabványnak számító SSL-t 
már ma is gyakran használják érzékeny adatok (például 
hitelkártyák száma, jelszavak) titkosított átvitelére. 

A háttérkiszolgálók és a Mobile Information Server kö- 
zötti adatbiztonságot egy virtuális magánhálózat 
(VPN) biztosítja, mely Internet Protocol Security-t (IP- 
Sec) használ. Az IPSec hitelesíti az adat küldőjét és 
megakadályozza a , spoofing"-ot (egy elterjedt támadá- 
si forma, melynek során az illetéktelen felhasználó meg- 
személyesít egy jogosult felhasználót, így próbál hozzá- 
jutni érzékeny adatokhoz). Az IPSec támogatja az ada- 
tok titkosítását is, ezzel is segít megakadályozni az il- 
letéktelen hozzáférést. 

A felhasználói azonosítók mindig titkosítottak. (Kivéve ak- 
kor, amikor éppen a WAP kiszolgálón vannak, és WTLS-ből 
éppen SSL-be huppannak át -— a szerk.) . 


] 


o 
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Hitelesítés 

Mivel a Mobile Information 2001 Server alaphitelesítést és 

már megszokott biztonsági protokollokat használ, bizton- 

sági beállításainak elvégzéséhez gyakorlatilag nem kell 

semmi újat tanulni. A biztonsági szabályok beállítása és a 

felhasználók hozzáadása egy MMC beépülő modul segítsé- 

gével végezhető el. A Mobile Information Server haszná- 
latához kétféle felhasználói fiók közül választhatunk: 

"1 Mobilazonosítók—speciális külső tartományi fióknevek 
és jelszók, melyek csak a Mobile Information Serveren 
keresztüli vezeték nélküli távoli eléréshez használhatók. 

"8 Natív azonosítók—szabványos Windows felhasználói 
fióknevek és jelszók. 


Mobilazonosítók 

A mobilazonosítók lehetővé teszik a WAP eszközök speciá- 

lis, Windows 2000 , felhasználóként" történő kezelését. A 

mobilazonosítók elkülönített kezelése még a cég adatainak 

jobb védelmét is elősegíti. 

A mobilazonosítók alkalmazásának számos további előnye van: 

"B A mobil felhasználói fiókok intranethez és Exchange-hez 

való hozzáférése le van tiltva, ezért használatuk bizton- 

ságosabb. A felhasználók csak a saját Exchange posta- 

fiókjukat és azokat az intranet oldalakat érik el, melyek 

mobil elérését a cég jóváhagyja. 

A mobil és Windows felhasználói fiókok és jelszavaik 

eltérnek egymástól, ezért illetéktelenek nem használ- 

hatják a mobilazonosítókat a vállalati erőforrásokhoz 

való hozzáféréshez. 

"B A mobil felhasználói fiókok beállításaitól függően 
használhatók hozzájuk számokból álló jelszavak (PIN) 
a szokásos szám/betű kombinációk helyett. Ez azért jó, 
mert ezeket könnyebb beírni a mobil eszközök kis mé- 
retű billentyűzetén. 

"0 A Mobile Information Server képes a mobil felhasználói 
fiókok jelszólejáratának ellenőrzésére, ezzel kikénysze- 
rít(het)i a jelszavak mobil eszközről történő frissítését. 





A mobilazonosítók kétféle módon adhatók meg: külön biz- 
tonsági csoportban (security group) vagy külön tartomány- 
ban. A mobil felhasználói fiókok beállításaitól függően a 
Mobile Information Server egy mobilfiók elő- vagy utóta- 
got illeszt a felhasználó Windows fióknevéhez. A felhasz- 
náló bejelentkezésekor a Mobile Information Server auto- 
matikusan hozzáilleszti az elő- vagy utótagot a fióknév- 
hez, ami szükségtelenné teszi, hogy a felhasználók több 
fióknevet használjanak. A felhasználóknak nem is kell tud- 
niuk, hogy a mobil felhasználói fiókjuk eltér a Windows- 
ostól, az elő- vagy utótag számukra láthatatlan. 


A következő ábrán látható, hogy hogyan ellenőrzi a Mobile 
Information Server a mobil fiókazonosítókat, és hogyan jele- 
níti meg az Exchange-en található tartalmat (jelen esetben a 
felhasználó Outlook Today lapját). A folyamat akkor kezdődik, 
amikor a felhasználó HTTP tartalmat kér. A Mobile Information 
Server kihívást (challenge) küld az ügyfélnek, melyben kéri a 
felhasználói azonosítót. Amikor az ügyfél elküldi az azonosí- 
tóit, a Mobile Information Server hozzáteszi a mobilfiók utó- 
tagot a felhasználó nevéhez, és ellenőrzi az azonosítókat az 
Active Directory-ban. Miután megkapta a felhasználó bizton- 
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sági jellemzőit, a Mobile Information Server átalakítja a HTTP ké- 
rést HTTP-Distributed Authoring and Versioning (HTTP-DAV) ké- 
réssé, és továbbítja ezt az Exchange kiszolgálónak. Az Exchange 
elküldi a HTTP-DAV választ a Mobile Information Server-nek, ami 
ismét átalakítja azt, de most Wireless Markup Language (WML) 
formátumúra, amit egy WAP-os telefon meg tud jeleníteni. 

4. A Mobile Information Server 


utótagot illeszt a névhez és így 
ellenőrzi a személyt 





2. A Mobile Information Server Y 

1. A telefon lekéri azonosítást kér Active 
az Outlook Today 3. A felhasználó megadja N Directory 
lapot § nevét és jelszavát j 

2—--at— Hz 

Szi 5. A Mobile Information Server 
fsatstssttkó megkapja a választ 
/ WAP Server ESSS e 
j Mobile Information / 7 

8. A Mobile Information Server Server ze 
tr alaszt MM alakítja, 7 A mobile Information Sörver Server 


és küldi a telefonra megkapja a HTTP választ 


/ 
6. A Mobile Information Server 
HTTP-DAV kérést küld az Exchange felé 


0 Az Outlook Today elérése mobilazonosítók használatával. 


Natív azonosítók 

Ha telepítés közben nem adunk meg mobil utótagot vagy má- 
sik tartományt, a Mobile Information Server alapértelmezés- 
ben a Windows tartományt, felhasználói azonosítókat és jel- 
szavakat fogja használni. Natív azonosítók használata esetén 
a felhasználók csak számítógépükről változtathatnak jelszót, 
mert a Mobile Information Server-rel nincs mód a szabványos 
Windows felhasználói fiókok jelszavának megváltoztatására. 
A natív azonosítók használata leegyszerűsíti a felhasználói 
fiókok kezelését, mert lehetővé teszi az egyszeri bejelentke- 
zést minden felhasználó számára, attól függetlenül, hogy mi- 
lyen elérési módot és eszközt használ. Néhányan a szabvá- 
nyos tartományi azonosítók mobil környezetben való haszná- 
latát bizonyára fölösleges biztonsági kockázatnak tartják, hi- 
szen a tűzfalon kívül a jelszavak nem mindenhol titkosítottak. 
A kétféle hitelesítési mód biztosításával a Mobile Information 
Server lehetővé teszi, hogy a cégek kiválasszák a számukra 
előnyösebb azonosítótípust. A mobilazonosítók használata 
biztonságosabb, a natív azonosítóké viszont kényelmesebb. 


A mobilalkalmazások és a biztonság 

Várható, hogy kifejlesztésre kerülnek olyan új mobilkészülékek 
és alkalmazások, melyek a Mobile Information Server bizton- 
sági modelljét használják. Néhány külső gyártó által készített 
készülék és alkalmazás biztosan képes lesz olyan Internetes 
protokollokat és jobb hitelesítési eljárásokat (például Digest 
Authentication) használni, melyeket a WAP eszközök jelenleg 
nem támogatnak. A Digest Authentication a felhasználók jel- 
szavait titkosított formában küldi a mobil eszközről a Mobile 
Information Server-re, így ezzel a hitelesítési eljárással fölös- 
legessé válik a külön mobilazonosítók használata, hiszen a jel- 
szavak sehol nem jelennek meg titkosítatlan formában. 

A Microsoft Mobile Information 2001 Server szoftverfejlesztő 
készletében (SDK) megtalálható az a dokumentációkat és stan- 
dard library COM modulokat tartalmazó eszközkészlet, melynek 
segítségével a fejlesztők megvalósíthatják az általuk készített 
alkalmazásokban az adatvédelmi és biztonsági funkciókat. 
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Jövőkép 

A Mobile Information 2001 Server a mai vezeték nélküli esz- 
közökkel megvalósítható legmagasabb szintű adatvédelmet 
és biztonságot nyújtja. A Mobile Information 2001 Server jö- 
vőbeni verziói továbbra is az Internetes és vezeték nélküli 
szabványok kombinációját fogják használni (például SSL és 
WTLS) , és támogatni fogják a például a következőket: 

"8 Passport: lehetővé teszi, hogy felhasználói a vele együtt- 
működő webhelyeket (például MSN, Hotmail, Expedia és 
buy.com) egyetlen felhasználói név és jelszó segítségével 
érjék el. A Passport tartalmaz egy opcionális , pénztárca" 
(.wallet") szolgáltatást, mellyel a felhasználók hitelkár- 
tyájuk számát, szállítási címüket és más olyan bizalmas 
információt tárolhatnak, mely az elektronikus vásárlások 
lebonyolításához szükséges. Minden passport tranzakció 
biztonságos SSL kapcsolatokon keresztül zajlik. 
Nyilvános kulcsú infrastruktúra (PKI): olyan összetevők 
csoportja, melyek együttműködésével megvalósíthatók a 
digitális aláírások és a bizalmas adatok titkosítása. 
Intelligens kártyák: a PKI egyik legfontosabb eleme, 
mely biztosítja a bizalmas adatok megváltoztathatatlan 
tárolását, és lehetővé teszi a felhasználói azonosítók asz- 
tali gépek és mobil eszközök közti átvitelét. 

Microsoft Mobile Explorer: mikroböngésző, mely képes 
WML és HTML tartalom megjelenítésére, és végponttól- 
végpontig terjedő biztonságos adatátvitelt biztosít az 
SSL segítségével. 


A Microsoft úgy látja, hogy az adatok biztonsága a vezeték 
nélküli Internet fejlődésével a végfelhasználóknak egyre fon- 
tosabb lesz. A Microsoft továbbra is igyekezni fog, hogy a 
Mobile Information 2001 Server következő verziói egyre biz- 
tonságosabbak legyenek, ennek érdekében alkalmazni fogja 
a legújabb biztonsági módszereket, hogy felhasználóinak 
biztonságos, titkos és hitelesített hozzáférést biztosítson 
bármely háttérkiszolgálón levő tartalomhoz. 

További információ: http://www.microsoft.com/miserver. 
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Nevem: Senki 


Sokan nem tudják, hogy minden Windows NT-ben (és a Win- 
dows 2000-ben is) található egy különleges felhasználó, 
akit úgy hívnak: ,". Természetesen idézőjel nélkül. Szokták 
emlegetni anonymous felhasználóként is, de nem azonos a 
webkiszolgáló anonymous böngészőjével, az IUSR cszámí- 
tógépnéve, illetve a másik hasonló, INAM cszámítógép- 
név: felhasználóval, ezért elterjedt a , null user" elnevezés 
is. ,Senkit" hiába is keresnénk a felhasználók listájában, 
mert nincs sehol. Illetve valahol mégiscsak van: tagja az 
Everyone (Mindenki) csoportnak. 


Kell ez nekünk? 

Bizony, ha nem is nekünk, de - sajnos - szükség van rá. Szá- 
mos olyan művelet, funkció létezik a Windows világban (há- 
lózatban), amihez az kell, hogy két vagy több számítógép 
együttműködjön. A null user-t (,, normális" esetben) maga az 
operációs rendszer használja, amikor különféle okokból be 
kell jelentkeznie egy távoli számítógépre. (Ilyen eset például 
maga a bejelentkezés (NetLogon), a megbízotti kapcsolat 
(trust) felépítése, és még sok más is.) A távoli eljáráshívás 
(Remote Procedure Call, RPC) lehetővé teszi, hogy egy fel- 
használó, vagy akár program távoli számítógépen található 
programokkal kommunikáljon, persze csak a hálózati beje- 
lentkezés után, a megfelelő jogosultságú felhasználó nevé- 
ben. Amikor pedig a számítógép nem egy adott felhasználó 
nevében tevékenykedik, kénytelen a null user-t választani. 
Lényeg, ami lényeg, a megfelelő eljárások távoli meghívása ál- 
tal a null user képes hozzáférni a felhasználók nevéhez, bizton- 
sági beállításaihoz (jelszóházirendhez, stb.), a számítógépre te- 
lepített, éppen futó rendszerszolgáltatások nevéhez, a megosz- 
tott könyvtárak listájához, és még sok minden máshoz is. 


Valakik már eleget voltunk... 
... legyünk inkább egy kicsit senkik -— mondja a hacker. És 
tulajdonképpen nem is kell nagyon összetörnie magát az 
ügy érdekében. Amikor egy távoli számítógép erőforrásai- 
hoz először szeretnénk hozzáférni, be kell jelentkeznünk. 
Az első bejelentkezés után (míg csak ki nem jelentkezünk, 
vagy ki nem rúgnak) az előzőleg megadott felhasználónév- 
vel tevékenykedhetünk. Ha megpróbálnánk mást választani, 
jönne a jól ismert hibaüzenet: ,The credentials supplied 
conflict with an existing set of credentials". Azaz, vagyunk, 
akik vagyunk, ne akarjunk más lenni. 
Pontosan ez az, amit a , senkiség" érdekében kihasználhatunk: 
ha egyszer null user-ként bejelentkezünk a távoli számítógép- 
re, a későbbi parancsaink már a null user nevében futnak le. 
Próbálkozzunk egy kicsit! Legyen az áldozat számítógép ne- 
ve , victim". Először jelentkezzünk be: 

net use t YWvictimlipc$ "" /user:"" 
A parancs szintaxisa talán ismerős, az Npc$ nevű rejtett 
megosztás minden Windows NT-n (és Windows 2000-en) megta- 
lálható, a gépeken futó processzek közötti kommunikációs csa- 
tornák kiépítésére való belépési pont. Kénytelenek vagyunk ezt 
használni, mert a , hagyományos" megosztásokhoz a null user 
kevés lenne. Így viszont sikerrel járhatunk. És hogy ez mire jó? 
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Miután a null user az Everyone csoport tagja, a bejelentke- 
zés után mindent megtehetünk, amit az Everyone megtehet. 
S milyen alapértelmezett jogosultsági beállításokat találunk 
a Windows NT alatt? Bizony, aki kapja, marja, legtöbbször a 
klasszikus Everyone - Full Control érvényesül. 

Pontosan ezért találták ki a Windows NT 4 Service Pack 3-ban 
az Authenticated Users csoportot. Ez a csoport mindössze 
annyiban különbözik az Everyone-tól, hogy a null user nin- 
csen benne. Ezért, amikor csak tehetjük, az Everyone helyett 
használjuk inkább az Authenticated Users-t. Számos lyukat 
befoltozunk ezzel, de sajnos azért marad még tennivaló. 

A gond ugyanis az, hogy a korábban már felsorolt, biztonsági 
jellegű adatok lekérdezésére való függvények a távoli eljárás- 
híváson keresztül a null user égisze alatt továbbra is elérhe- 
tők. Szinte az összes biztonsági ellenőrző (és kalóz-) eszköz ví- 
gan listázza a felhasználóink nevét, hogy kinek mikor jár le (és 
lejár-e egyáltalán) a jelszava, és az is azonnal kiderül, ha az 
igazi Administrator fiókot átneveztük valami másra. 

A Windows NT 4.0 Service Pack 3 szerencsére bevezetett 
egy másik újítást is, amit RestrictAnonymous néven isme- 
rünk. Ez egy (DWORD) típusú registry érték, amit ha a 
HKLMNYSTEM KurrentControlSet Control SA kulcs alatt 
létrehozunk, és értékét 1-re állítjuk, megnehezíti a bizton- 
sági adatok és erőforrások lekérdezését. 


A CI HKEY. LOCAL MACHINE A BZ EZ Dán ee 
HARDWARE (value not set) 
SAM E 647376 31 5t 300000 
SECURITY 00 300000 00 20 00 00 
a SOTOBÁE - 4650 4e 57 43 4c 4e 540000 
CI 0one 
(a CI Controlset001 
CI Controtset002 
CiarentControlSet 
z CI Control 





(My ComputettHKEY. LOCAL. MACHINENSYSTEMICurentControlSetNControtL a 


5 Windows NT 4-en a RestrictAnonymous érték létreho- 
zása és 1-re állítása létfontosságú 


A beállítás hatására bizonyos távoli eljárások a null user 
számára nem lesznek elérhetők (egyszerű jogosultságlistákat 
kapnak az eljárások, ahova a null user nem került bele) . Így 
- gondolhatnánk - elbúcsúzhatunk a felhasználók, megosz- 
tások, biztonsági erőforrások távoli kilistázásától. 


Semmi sem az, aminek látszik... 

Timothy M. Mullen [1] (és nyilván még sokan mások) ugyanis 
vették a fáradtságot, és kipróbálták, hogy valójában mit tilt, 
és mit nem a RestrictAnonymous. Nyilvánvaló, hogy mindent 
nem tilthat, hiszen ez a funkcionalitás a Windows NT hálóza- 
ti működésének alapját képezi. Kiderült, hogy például a fel- 
használónevet és a hozzátartozó biztonsági azonosítót (SID) 
összerendelő függvények továbbra is működnek. Ha valakinek 
a birtokában van a user2sid és sid2user nevű eszköz, kipró- 
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bálhatja, hogy a RestrictAnonymous beállítás dacára is sike- 
resen használhatók. Szabadon maradt ezen kívül egy olyan el- 
járás is, ami egy adott azonosítójú felhasználó biztonsági 
adatait adja vissza... A [2] címről letölthető userinfo.exe ne- 
vű kis eszköz a következő választ adja egy ismert nevű fel- 
használó lekérdezésére (Windows 2000-nél is!): 


c:VWSuserinfo WWwictim userl 
UserInfo v1.5 - thoréhammerofgod.com 


Ouerying Controller NWictim 


USER INFO 

Username: userl 

Full Name: Elso felhasznalo 
Comment : (ures jelszoval) 
User Comment: 

User ID: 1004 

Primary Grp: 513 

Privsz User Privs 
OperatorPrivs: No explicit OP Privs 


SYSTEM FLAGS (Flag dword is 66049) 
User"s pwd never expires. 





MISC INFO 

Password age: Sat Mar 10 22:46:47 2001 
LastLogon: Thu Jan 01 0 00 1970 
LastLogoff: Thu Jan 01 00:00:00 1970 


Mon Dec 31 23:00:00 2001 
Unlimited 


Acct Expires: 
Max Storage: 

Workstations: 
UnitsperWeek: — 168 


Bad pw Count: o 

Num logons: o 

Country code: 0 

Code page: o 

Profile: WMsuicideluser1 
ScriptPath: userlon. cmd 
Homedir drive: 

Home Dir: c:Wserstuserl 


PasswordExp: o 


Logon hours at controller, GMT: 


Hours- 12345678901N12345678901M 
Sunday 000000000000000000000000 
Monday 000000011111111110000000 
Tuesday 000000011111111110000000 
Wednesday 000000011111111110000000 
Thursday 000000011111111110000000 
Friday 000000011111111110000000 
Saturday 000000000000000000000000 


A korlátozott hozzáféréshez képest elég bőbeszédű adathal- 
maz, nem? :-) És még nincs vége. 


Aki ismeri a SID felépítését, az tudja, hogy a SID egy sokje- 
gyű azonosító, ami tartalmazza a tartomány és a felhasználó 
azonosítóját egyaránt. Ugyanazon tartomány felhasználóinak 
SID-je csak az úgynevezett relatív ID-ben (RID) különbözik, 
az (igazi) adminisztrátor RID-je, bárhogy is hívják, 500, a 
létrehozott felhasználók RID-je valahol 1001-nél kezdődik és 
az újabb felhasználók létrehozásával folyamatosan nő. 
Kiváncsiak vagyunk a felhasználók listájára? Fogjunk egy is- 
mert felhasználónevet (administrator, guest), keressük ki a 
hozzá tartozó SID-et, vágjuk le a végét, majd ragasszunk 
hozzá tetszőleges RID-t, és kérjünk információt a felhasz- 
nálóról, ha létezik. Ha nem, próbálkozzunk más RID-vel. 
Pofonegyszerű, nemde? A [3] címről letölthető userdump- 
.exe pontosan ezt teszi. (Itt jegyezném meg, hogy az ad- 
ministrator és guest felhasználó átnevezése ezt a trükköt 
megnehezíti. Sebaj, akkor használjunk egy csoportnevet, 
vagy akár a számítógép nevét :-) )... 
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Mit tehetünk akkor? 

Windows NT 4 hálózatban használjunk tűzfalat. Mivel a tá- 
voli eljáráshívás (RPC) a 139-es TCP portot használja, e port 
blokkolása megoldja a problémát. Legalábbis a tűzfalon 
kívülről érkező támadások esetén. További lehetőség a 
NetBIOS over TCP/IP letiltása, de akkor el kell búcsúznunk 
a Windows hálózati funkcióktól. Egy átmeneti megoldás lehet, 
hogy egy virtuális hálózati kártyát (MS Loopback Adapter) te- 
lepítünk a gépre, és csak arra engedélyezzük a NetBIOS 
használatát. A NetBIOS szolgáltatások ekkor a számítógépen 
kívülről ugyan nem érhetők el, de legalább maga az operá- 
ciós rendszer, és a NetBIOS kommunikációt igénylő helyi 
komponensek, szolgáltatások nem szenvednek csorbát. 


Van remény? 
A Windows 2000-ben a biztonsági házirenden keresztül is 
hozzáférhetünk a RestrictAnonymous beállításhoz: 


Aton Yew [[ o 5 Olmix BZ] 
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5 Anonymous beállítások a Windows 2000 biztonsági 
házirendjében 


Látható, hogy itt egy harmadik lehetőség is van: ,No access 
without explicit anonymous permissions". Ha ezt beállítjuk 
(ami egyébként a 2-es Restrictanonymous érték) , a null user 
nem kerül bele az Everyone csoportba, így már annyit sem 
tehet, mint eddig. Ezt a beállítást viszont csak akkor hasz- 
nálhatjuk, ha tiszta Windows 2000 környezetben vagyunk; 
a Windows 9x, Windows NT ügyfelek többé nem lesznek ké- 
pesek bejelentkezni a rendszerbe. 


Fülöp Miklós 
mick Onetacademia.net 


[1] http://www.securityfocus.com/focus/microsoft/ 
nt/restrict.html 
[2] http://www.securityfocus.com/tools/1930 


[3] http://www.se: 
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Bevezetés 

A mai, korszerű adatbázisok egyik legfontosabb jellemzője, 
hogy sokan használják egyidejűleg. Mivel a felhasználók, al- 
kalmazások egymástól függetlenül próbálják meg módosítani 
a táblák tartalmát, gyakori a konfliktushelyzet. Ilyenkor kez- 
denek lelassulni a rosszul megtervezett adatbázisok, és jön- 
nek az időtúllépésről, valamint a misztikus dead-lock-okról 
szóló hibaüzenetek, nem beszélve a logikailag hibás adatok- 
ról. Ebben a részben részletesen kitárgyaljuk a zárolások 
okait és fajtáit, a következő számunkban pedig a dead-lock- 
ok misztikus világáról lebbentjük le a fátylat. Cikksorozatunk 
mostani fejezete elég nehéz, ám annál fontosabb témakörrel 
foglalkozik, ami nélkül igen nehéz megbízható és hatékony 
adatbázisokat tervezni az SOL Server 2000-re. 


Optimista vagy pesszimista? 

Nézzünk meg egy klasszikus ügyfél-kiszolgáló alkalmazást, 
ami kurzorok használatával módosítja az adatokat. A leg- 
több Visual Basic és Visual Cs alkalmazás ilyen. 

Tegyük fel, hogy van egy adatbázis, amely egy cég alkalmazot- 
tait tartja nyilván. Kiss Béla cégen belüli pozíciója megválto- 
zik, kap egy Senior jelzőt a rangja elé. Ezzel együtt a lakcíme 
is megváltozott, amiről külön értesíti az egyik HR-es hölgyet. 
Az emberi erőforrás menedzsmenten lelkes emberek dolgoz- 
nak, és azonnal nekilátnak a változás adatbázisba rögzítésé- 
nek. A lelkesedésük nagyobb, mint a munkaszervezettségük, 
így egyszerre ketten kezdik el módosítani a kérdéses alkal- 
mazott adatait az adatbázisban. Tegyük fel, hogy mindket- 
tejük előtt ki vannak listázva Béla adatai, és nekiállnak mó- 
dosítani a rekordot. Az első a lakcímet és a rangot, a máso- 
dik csak a rangot írja át. Megnyomják az , Elment" gombot, 
és tegyük fel, hogy az első hölgy a gyorsabb. Mi történik? 
Két eset lehetséges. Egy butább adatbáziskezelő vagy egy 
rosszul megírt ügyfélalkalmazás esetén az első ügyfél által 
kért változtatás beíródik az adatbázisba, amit követ a máso- 
dik ügyfél módosítása. Mivel mindketten ugyanazokból a 
kiinduló adatokból módosított adatokat írják vissza, a má- 
sodik módosítás fejbe csapja az elsőt, azaz a végleges re- 
kordban nem lesz módosítva a lakcím, mert a második hölgy 
csak a rang mezőt módosította. A probléma nem az, hogy ez 
így megtörténhet, hanem az, hogy az ügyfélprogramok nem 
is szereznek róla tudomást, hogy módosításvesztés történt. 
Az iménti helyzetben felvázolt helyzetet hívjuk az elveszett 
módosítások problémájának. Hogyan védekezik az ilyen 
helyzetek ellen egy okos adatbáziskezelő? Amikor egy ügy- 
félprogram lekér egy adott rekordot az adatbáziskezelőtől, 
akkor a szerver megjegyzi, hogy valaki letöltötte a rekor- 
dot, mert módosítani szeretné. Amikor más ügyfelek is sze- 
retnék ugyanezt megtenni, akkor kétféle dolog történhet. 
Ha az első ügyfél optimista zárolás felhasználásával kérte le 
a rekordot, akkor a hasonlóan eljáró további ügyfelek is 
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let esetén az adatbáziskezelő megnézi, hogy megváltozott- 
e az adatbázisban tárolt sor a korábban lekért állapothoz 
képest (annyira nem optimista, hogy vakon megbízzon ben- 
ne, hogy nem változott :). Ha igen, akkor a próbálkozónak 
már csak egy hibaüzenet jár, ami arról tájékoztatja, hogy a 
módosítani kívánt rekordot már valaki más módosította: 


Optimistic concurrency check failed. The row was 


modified outside of this cursor. 


Ilyenkor nincs mit tenni, újra le kell kérni a módosított 
adatokat, újra beírni a változtatásokat, és újra megpróbál- 
ni beküldeni a változtatási kérelmet. Ha ezúttal mi voltunk 
a leggyorsabbak, akkor nyertünk, és a mi módosításunk lesz 
érvényes. Ha nem, try again... Nyilvánvaló, hogy egy olyan 
rendszerben, ahol gyakoriak a módosítások, ott nem meg- 
felelő ez az eljárás, mert túl gyakoriak az ütközések. 

A másik stratégia úgy gondolkodik, hogy ne ringassuk hiú 
ábrándokba a második, harmadik, satöbbi ügyfelet, hanem az 
első alkalmazás, ami módosítani akar egy rekordot lefoglalja 
azt, és a többiek addig nem is tudják lekérni a rekordot 
mindaddig, amíg az első fel nem oldja a zárolást. Ezt a stra- 
tégiát pesszimista zárolásnak hívjuk. Ez is egy elfogadható 
hozzáállás, ráadásul egyszerűbb implementálni a várakozást, 
mint lekezelni a sikertelen módosítást. (Gyakorlatilag nem 
kell tenni semmit, mert az adatbázist elérő metódus nem tér 
vissza addig, amíg a módosítandó rekord fel nem szabadul.) 
Például egy helyfoglaló rendszernél csak ez a módszer tud 
helyesen működni, hisz optimista esetben az operátor még 
szabadnak láthat olyan helyeket, amelyeket már rég lefog- 
laltak más operátorok. Inkább ne is láthassa azokat a he- 
lyeket, amelyeket éppen valaki más próbál lefoglalni. 

Az eddigi példában olyan helyzetről beszéltem, amikor a re- 
kordokat kurzor segítségével kértük le, és a kapott recordset- 
en keresztül módosítjuk az adatokat. Ez a fajta megoldás a 
mai világban egyre ritkább, és különösen a Webalkalmazások- 
ban nem ilyen módon kezeljük az adatokat. Azokban általá- 
ban tárolt eljárások segítségével módosítjuk a sorokat. Ilyen- 
kor már nagyon könnyen fejbe lehet csapni a konkurens mó- 
dosítások eredményét, hisz az adatok lekérése és a módosí- 
tott adatok visszaírása közben megszakad az ügyfélprogram 
(a Webalkalmazás) kapcsolata az adatbázissal, így az adatbá- 
zisnak még esélye sincs arra, hogy zárolással vagy Voodoo va- 
rázslással megóvjon minket a módosítások elvesztésétől. 
Tegye a szívére a kezét minden Webalkalmazás fejlesztő! 
Gondolt már valaha erre a problémára? Vagy csak mechani- 
kusan visszaírja a módosított eredményeket a forrástáblá- 
ba? Vesszen a lassabb? Az ADO természetesen ilyen helyze- 
tekre is biztosít megoldást, de használjuk ezeket? (A jövő- 
ben mindenképpen áldozunk egy-két cikket a témának.) 
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DEVELOPER TRANSACT SAL (VI. RÉSZ) 
SOL Server tranzakciók 

Szakadjuk el egy kicsit a kurzort használó ügyfélprogramok- 
tól, és evezzünk át a tiszta SOL Server megoldásokhoz, va- 
lamint a tárolt eljárásokat használó alkalmazásokhoz. Néz- 
zük meg, hogy a tranzakciók során mennyire vagyunk vé- 
dettek mások adatmódosításai ellen. 

Kiindulásként álljon itt egy kérdés. Alapértelmezett beállítások 
mellett biztos lehetek benne, hogy egy tranzakción belül há- 
borítatlanok maradnak az általam használt táblák, miközben 
mások is dolgoznak az adatbázisban? Legtöbben azt gondol- 
ják, igen. Ha biztos akarok lenni abban, hogy a tábláimat nem 
változtatják meg a hátam mögött a tranzakcióm alatt, akkor 
elég BEGIN TRAN és COMMIT TRAN közé rakni az utasításaimat, 
és minden rendben lesz? Biztos? Egyáltalán nem. Járjuk körbe 
ezt a témát, mert ennek megértése nélkül senki nem mondhat- 
ja el magáról, hogy konzisztens adatbázist tud tervezni. 


A zárolások fajtái 

Annak érdekében, hogy az SOL Server szabályozni tudja az ada- 
tokhoz való párhuzamos hozzáféréseket, a védendő adatokra zá- 
rolásokat helyez el. Az SOL Serverben többféle zárolási típus 
van, és mindegyiknek van egy meghatározott viselkedése. Pél- 
dául más zárolást kell használjon a szerver az adatok olvasása 
során (SELECT), hisz ilyenkor általában csak azt kell megakadá- 
lyozni, hogy más tranzakció módosítsa az éppen olvasás alatt ál- 
ló adatokat. Ezzel szemben például egy adatmódosító tranzak- 
ció közepette nem lenne szerencsés engedni a többi tranzak- 
ciót, hogy olvassa az éppen módosítás alatt álló adatokat, plá- 
ne, hogy módosítsa ugyanazt. Nyilván ehhez másféle zárolásra 
van szükség. Tekintsük át a legfontosabb zárolási típusokat! 
Mint említettük az adatok olvasása során meg kell akadályoz- 
ni, hogy az éppen kiolvasott adatokat mások módosítsák az 
olvasási művelet közben, de meg kell engedni, hogy mások 
is olvashassák, hisz az veszélytelen a mi tranzakciónkra néz- 
ve. Ehhez az SOL Server Shared lock-okat helyez el az olva- 
sott adatokra (a könnyebb követhetőség kedvéért nem fordí- 
tottam le a zárolások nevét, és az egyszerűbb olvashatóság 
miatt a zárolás eredetijét, a lock-ot is meghagyom). 

Ha egyszerre több tranzakció is olvassa ugyanazt az adatot, 
akkor mindegyik elhelyezi a maga Shared lock-ját a rekordo- 
kon, és addig rajta is tartja, amíg nem végez az olvasással. 
Az adatmódosító utasítások (INSERT, DELETE és UPDATE) 
alatt nem szabad másnak olvasni a módosítandó adatokat, 
ilyenkor a szerver Exclusive lock-ot helyez el a sorokon. Az 
Exclusive lock mellett más nem helyezhet el semmilyen zá- 
rolást a sorokra, meg kell várnia, míg az adatmódosítás be- 
fejeződik, és a tranzakciót így vagy úgy, de be nem fejezik. 
A legtöbb esetben ezzel az esettel kerülnek szembe az adatbá- 
zisfejlesztők és üzemeltetők, azaz, hogy egy hosszú ideig tar- 
tó adatmódosító tranzakció zárol egy bizonyos adatmennyisé- 
get, így az egyéb adatolvasó vagy módosító tranzakcióknak 
várni kell a módosítás befejezéséig. Ezt sokan tévesen dead- 
lock-nak azonosítják, pedig ennek semmi köze nincs ahhoz. 
Egyszerűen csak egy hosszú idejű tranzakció blokkolja a többi 
tranzakció munkáját. Az SOL Server Enterprise Manager Mana- 
gement, Current Activity, Lock/Process ID alatt találhatjuk 
meg a szerveren a zárolásokat megjelenítő grafikus alkalma- 
zást. Ennek segítségével azonosítható az a tranzakció, ami 
blokkolja a többit (felkiáltójeles emberke ikon). Ezen a nyomon 
elindulva meg lehet keresni, és át lehet írni a bűnös tranzak- 
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ciót. Aki nem szereti a grafikus felületeket, annak az sp lock 
tárolt eljárást ajánlom a zárolások megfigyelésére. 

Az UPDATE rendhagyó művelet a többi háromhoz képest, mert 
az első fázisban fel kell olvasnia a módosítandó adatokat, a 
másodikban pedig módosítani azt. Emiatt az olvasási részben 
Shared lock-ot kell elhelyezzen az adatokon, a módosítás s0- 
rán pedig Exclusive lock-ot. Az ő kettős természete miatt ka- 
pott is egy saját zárolási típust, amit Update lock-nak hívnak. 
Az UPDATE az adat olvasási fázisban Update lock-ot rak a so- 
rokra, és a tényleges módosítás megkezdés előtt felemeli azt 
Exclusive lock-ra. Azért nem Shared lock-ot használ, mert az 
Update lock nem engedi meg, hogy mások is igényeljenek Up- 
date lock-ot ugyanazokra az adatokra, így nem tudja más meg- 
módosítani az adatokat a felolvasás és a módosítás között. A 
dead-lock-ok megelőzésében nagyon fontos szerepe van az 
Update lock-nak, amiről a következő számban írok bővebben. 
Schema Modification lock-ot az adatbázis szerkezetét mó- 
dosító utasítások (például ALTER TABLE) helyeznek el a 
megfelelő objektumokon, hogy közben nehogy mások is 
megpróbálják ugyanazt módosítani. 

A lekérdezések fordítása közben a szerver Schema Stability 
lock-al akadályozza meg a lekérdezésben szereplő táblák és 
egyéb objektumok szerkezetének módosítását. 


A zárolások finomsága 

Eddig elég homályosan fogalmaztam meg, hogy az SOL Ser- 
ver valójában mekkora adatmennyiségeket zárol a tranzak- 
ciók során. Most nézzük meg, hogy milyen egységekben tud 
adatokat zárolni a szerver. 

A legfinomabb zárolási egység a sor. Ez képes egyetlen re- 
kord zárolására, azaz miközben egy sort módosítunk, egy 
másik tranzakció képes a mellette található sor (reklord) ol- 
vasására vagy módosítására. 

Ha egy lapon (8 kByte-os egység, amely a sorokat tartalmazza) 
sok sort kellene zárolni, akkor a szerver inkább zárolja a teljes 
lapot, ahelyett, hogy sok sor-zárolást kellene nyilvántartania. 
Egyes esetekben, amikor olyan sok módosítás történik, hogy 
az szinte egy egész tábla tartalmát érinti, a szerver inkább zá- 
rolja az egész táblát, semmint egyedi lapokat, ezzel a zárolá- 
sok nyilvántartásához szükséges erőforrásokat spórolva. 

Az SOL Server automatikusan választja ki, hogy mikor milyen 
finomságú zárolásra van szükség. A tranzakció által érintett 
sorok számától függően keres olyan szintű zárolást, ami még 
elég finom ahhoz, hogy ne korlátozza jelentősen a többi 
tranzakció futását, de ne is kelljen nagyon sok lock-ot nyil- 
vántartania. A szerver egy tranzakció lefutása közben is képes 
változtatni a zárolás finomságát. Lehet, hogy elindul sorzáro- 
lással, ám a sorok zárolása közben észreveszi, hogy már olyan 
sok sort kell nyilvántartania, hogy érdemesebb lenne áttérnie 
az egész tábla zárolására. Ezt a folyamatot, amikor egy fino- 
mabb, de nagy számú zárolásról a szerver áttér egy dur- 
vább, nagyobb tartományra ható, de kevesebb számosságú 
zárolásra zárolás eszkalációnak (Lock Escalation) hívjuk. Ha 
tudjuk, hogy a tranzakciónk nagyon sok sort fog érinteni, 
akkor lehet, hogy érdemes a szervernek súgni, hogy nem ér- 
demes sorzárolástól indulva végiglépkednie a zárolásokon, 
hanem rögtön kezdje például tábla szintű zárolással. Lehet, 
hogy így olyan tranzakciókat is blokkolunk, amelyeket sor 
vagy lap zárolással nem befolyásolnánk, de a kis számú zá- 
rolás nyilvántartása miatt a tranzakciónk lehet, hogy sok- 
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kal gyorsabban fut le, így végeredményben kevesebb blok- 
kolást okozunk a többi tranzakció felé. 

Más esetben lehet, hogy az SOL Server egy egész táblát zárol- 
na, és így más tranzakciók nem tudnának abban dolgozni, 
például adatokat beszúrni. Tipikus példa erre, amikor egy 
hosszú idejű lekérdezést futtatunk, ami múltbeli adatokkal 
foglalkozik, miközben záporoznak be a táblába a mai naphoz 
tartozó sorok. Lehet, hogy a lekérdezés akár a sorok első 
999-át érinti, így a szerver nyilvánvalóan egy darab tábla zá- 
rolással lefoglalja a tranzakciónk számára a táblát, ám így az 
adatokat beszúró alkalmazás nem tud írni sorokat a tábla vé- 
gébe. Ilyenkor lehet, hogy például lapszintű zárolást erőltet- 
ve a tranzakciónk nem 5 perc, hanem fél óra alatt fut le a sok 
zárolás adminisztrációja miatt, de eközben az adatokat beszú- 
ró alkalmazás egy pillanatig sem állt le. Azaz vannak esetek, 
amikor szélesíteni akarjuk a zárolások tartományát, és van- 
nak, amikor szűkíteni, az alkalmazásunk logikájától függően. 
Hogyan befolyásolhatjuk az SOL Servert a zárolások finom- 
ságát illetően? A kérdésre a lock hint-ek adnak választ, a 
cikk utolsó részében. 

A végére hagytam egy különleges zárolási típust, amely az 
előbbiekkel ellentétben nem fix méretű zárolást valósít 
meg. Ez az index-tartományzárolás. Bizonyos esetekben 
(SERIALIZABLE tranzakciók, lásd később) szükség van arra, 
hogy egy lekérdezés WHERE feltételében definiált határok 
között ne lehessen új adatokat beszúrni. Például lekérdez- 
zük az 5 és a 13 közötti azonosítójú sorokat, és nem sze- 
retnénk, ha a tranzakciónk alatt valaki más beszúrna új s0- 
rokat olyan azonosítóval, amely 5 és 13 közé esik. Ebben 
az esetben a szerver az indextartomány két végét lezárja 
Key lock-kal, így a megadott tartományba nem enged új s0- 
rokat beszúrni. Ennek a zárolásnak a hossza nyilvánvalóan 
nem fix, hanem a lekérdezés függvénye. Természetesen ez 
a zárolás csak akkor tud működni, ha a tartományokat de- 
finiáló mezőre van index létrehozva. Ha nincs, akkor a szer- 
vernek nincs mit tennie, tábla zárolást kell alkalmaznia. 


Zárolás kompatibilitás 

Mi történik, ha az egyik tranzakció zárolásokat helyez el 
bizonyos adatmennyiségen, miközben mások ugyanezt 
akarják megtenni, ugyanazokra az adatokra? Ez attól függ, 
hogy milyen zárolás van éppen az adatokon, és milyet 
igényel egy másik tranzakció. 

Vannak zárolások, amelyek szeretik egymást, és vannak, 
amelyek nem. Nyilvánvaló, hogy a Shared lock szereti a 
Shared lock-ot, azaz, ha az egyik tranzakció olvassa az 
adatokat, és emiatt Shared lock-okat helyez el az olvasott 
sorokon, a másik tranzakció veszélytelenül felolvashatja 
ugyanazokat a sorokat, azaz ő is elhelyezheti a Shared 
lock-jait ugyanazokon a sorokon. Ha eközben egy harma- 
dik résztvevő is beszáll, aki módosítani akarja a kétszere- 
sen is zárolt (Shared módon) sorokat, akkor neki bizony 
várnia kell egészen addig, amíg a másik két tranzakció be 
nem fejezi az adatok olvasását, és le nem veszi a lock-ja- 
it. Ez is a klasszikus blokkolás esete, amikor egy adatmó- 
dosító utasításnak várnia kell arra, hogy elhelyezhesse az 
Exclusive lock-jait az adatokon. Miután kivárta a sorát, és 
felrakta a kizárólagosságát biztosító zárolását, senki más 
semmilyen zárolást nem tud elhelyezni mindaddig, amíg az 
be nem fejezi a módosító tranzakciót, és le nem veszi az 
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Exclusive lock-ot. Nyilván ebből adódik e zárolás neve is. 

Azaz abban az esetben, ha egy tranzakció szeretne valami- 
lyen zárolást elhelyezni egy adathalmazon, az SOL Server 
ellenőrzi, hogy a már fennálló zárolások alapján kiadható- 
e a kért típusú zárolás. Ha igen, akkor megkapja, a zárolás 
feljegyzésre kerül, és a trónkövetelő tranzakció megkezd- 
heti a munkáját. Amennyiben viszont olyan zárolást kért, 
ami logikailag nem összeegyeztethető a már meglévőkkel, 
akkor a zárolást kérő utasítást a szerver mindaddig felfüg- 
geszti, amíg meg nem szűnnek az akadályozó zárolások. Az 
igényt természetesen feljegyzi, és a többi zárolás fokoza- 
tos ,lehullása" alatt mindig ránéz, hátha már kiadható a 
kért zárolás. Miközben az igénylő vár a lock-jára, lehet, 
hogy más tranzakciók is jelentkeznek zárolási igénnyel, és 
azok között akár olyan is lehet, ami összeegyeztethető len- 
ne a már fennálló zárolásokkal. Ilyenkor mit tegyen a szer- 
ver? Engedje őket, hogy elhelyezzék a saját zárolásaikat, 
vagy addig ne engedje őket szóhoz jutni, amíg a már régó- 
ta várakozó tranzakció meg nem kapja az áhított zárolá- 
sát? Ha engedi őket, akkor azok lefuthatnak a várakozó 
előtt, ám előfordulhatna az, hogy a sok újabb és újabb ké- 
rő soha nem engedné, hogy a várakozó megkapja a zárolá- 
sát. Azaz ezzel a stratégiával kiéheztetnénk azokat a 
tranzakciókat, amelyek olyan zárolásokat kérnek, amelyek 
általában nem kompatíbilisak a már meglévőkkel. A gya- 
korlatban ez azt jelentené, hogy egy módosító utasítás s0- 
ha nem kapná meg az Exclusive lock-ját, ha az egymás 
után érkező olvasó (SELECT), Shared lock-okat elhelyező 
utasításokkal operáló tranzakciók időben átlapolják egy- 
mást. Nyilván ezt nem engedhetjük meg. Emiatt az SOL 
Server nem engedi zárolni a további kérőket, amíg a már 
fennálló zárolási igényeket nem elégítette ki. Ez persze azt 
is jelenti, hogy egy adatmódosító utasítás után akár 
hosszú sorokban állhatnak a csak olvasni akaró tranzak- 
ciók, akik ugyan nyugodtan olvashatnák a Shared lock-kal 
védett sorokat, de nem tehetik, mert a módosító utasítás 
vár az Exclusive lock-jára. Gyönyörű hosszú blokkolási lán- 
cok tudnak így kialakulni. Mit lehet tenni ellenük? 

A legegyszerűbb védekezés, hogy a módosító tranzakciókat 
nagyon rövidre tervezzük. Nem szabad egy adatmódosító 
tranzakcióba felhasználói beavatkozásra váró rutint elhe- 
lyezni! Mi van, ha közben elmegy ebédelni? Mire visszaér, 
az adatbázis adminisztrátor már a tízezredik feltorlódott 
tranzakciót fogja látni a le nem zárt módosító tranzakció 
miatt! Természetesen ezt nem szabad megengedni. 

A másik eszközünk a zárolás finomságának állítása, azaz 
nem hagyjuk, hogy a módosító tranzakció túl nagy falatot 
zároljon le kizárólagosan a táblákból. Erre valók a lock 
hint-ek, amelyekről hamarosan szólok. 

Egy valamiről még nem beszéltem. Honnan tudja az SOL 
Server, hogy melyik zárolási típus melyik másikkal kompa- 
tíbilis? Nos, erre a célra van egy táblázata, és abból olvas- 
sa ki. Ezt a táblázatot az SOL Server tervezői alkották meg, 
figyelembe véve az egyes zárolások természetét, és hogy 
melyik futhat párhuzamosan a másikkal anélkül, hogy az 
adatbázis épségét veszélyeztetné. A Books Online a Lock 
Compatibility című fejezetben ismerteti ezt a táblázatot. 
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Az Intent lock-ok 

Megnéztük, hogy az SOL Server csak akkor helyez el egy újabb 
zárolást ugyanazon az adaton, ha az igényelt zárolási típus kom- 
patíbilis a már fennállóval. Azonban hogyan hasonlít össze kü- 
lönböző finomságú zárolásokat? Ha van egy Exclusive lock egy 
soron, akkor rakható Shared lock ugyanarra a táblára? Ilyen kér- 
dőjeles helyzet nagyon sok kialakul, hiszen minden tranzakció 
más finomságú zárolást használhat. Nézzünk erre egy példát. 
Az első tranzakció Shared lock-kal lefoglal 3356 sort egy 
táblában. Egy másik tranzakció lefoglal 10 lapot Exclusive 
módon. Van még 23 éppen futó tranzakció, amelyek 12354 
darab Shared és 5 darab Exclusive lap szintű lock-ot tarta- 
nak a táblán. Ezután egy sokadik tranzakció tábla szinten 
szeretne Shared lock-ot. Mit tud tenni a szerver, hogy 
megállapítsa, megkaphatja-e? Végig kell néznie az összes 
(335641041235445 darab) zárolást, és meg kell keresnie, 
hogy van-e köztük olyan, amelyik Exclusive módon birtokol- 
ja a tábla valamely szeletét. Ha van, akkor nem adhatja ki 
a tábla szintű Shared lock-ot. Ha közben egy-egy tranzak- 
ció befejeződik, és engedi el a zárolásait, akkor a lock ma- 
nager-nek minden esetben végig kellene nézni az összes 
még megmaradt zárolást, hogy maradt-e még Exclusive, és 
ha már nem, akkor kiadható a tábla szintű Exclusive lock. 
Ez az eljárás igen lassú volna. Ennek elkerülésére az SOL Ser- 
ver trükkösen foglalja le a kisebb finomságú (sor, lap, ex- 
tent) zárolásokat. Ha egy tranzakció elhelyez akár csak egy 
sornyi zárolást is egy táblán, akkor ezzel együtt a szerver el- 
helyez egy ugyanolyan típusú (Shared vagy Exclusive) lock- 
ot a sort tartalmazó lapra és táblára is, ám azt csak szándék- 
nyilatkozatként Intent Shared vagy Intent Exclusive-ként 
megjelölve. Ezek után a teljes táblára Exclusive lock-ot kérő 
tranzakció igénye könnyen eldönthető, hisz elég megnézni, 
hogy van-e nem kompatíbilis Intent lock a táblán. 

Ez az eljárás nemcsak tábla szinten működik, hanem minden 
olyan szinten, amikor egy kisebb finomságú zárolást kér egy 
tranzakció. Így egy Exclusive sor lock-ot kérő tranzakció kap 
egy , valódi" Exclusive lock-ot a soron, és kap egy lap és táb- 
la szintű Intent Exclusive-et is. Ha az Intent lock-ok elhelye- 
zése közben kiderül, hogy a sort tartalmazó lapon már van 
egy Shared lock, akkor a sorra sem szabad kiadni az Exclusive 
lock-ot, mert előfordulhat, hogy belemódosítunk olyan sorba, 
amit valaki más olvas lap szinten (pont ezért rakott rá Shared 
lock-ot) . Azaz az exkluzív sor-zárolás kiadását megakadályoz- 
hatja egy, a sort tartalmazó lapon már létező Shared lock, így 
az Intent lock-ok elhelyezése (helyesebben meghatározása) 
közben kiderül a zárolási igény kompatibilitási kérdése is. 


A tranzakciók elszigeteltségi szintjei 

Láttuk, hogy a párhuzamosan futó tranzakciók többé-kevés- 
bé hatnak egymásra, befolyásolják egymás működését. Ter- 
mészetesen egy adatbázisban nem alapozhatunk , többé-ke- 
vésbé" szabályokra, valamilyen egzakt módszer kell annak 
eldöntésére, hogy miközben az egyik tranzakció valamit 
működik egy táblán, a többi tranzakció ebből mit lát, illet- 
ve mit tehet a kérdéses táblával. Ennek a kérdésnek a sza- 
bályozásával az ANSI SOL 92-es szabvány részletesen 
foglalkozik, és ad is ajánlást egy lehetséges megvalósításra. 
A szabvány a tranzakciók elszigeteltségét négy szintre 
bontja. Minél inkább haladunk előre a szintekkel, annál keve- 
sebb hatással vannak egymásra a tranzakciók, cserébe annál 
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kisebb az esély a tranzakciók párhuzamos végrehajtására. Az 
egyik oldalon nyerünk valamit, cserébe a másikon veszítünk. 
SOL Serverben az elszigeteltségi szinteket a tranzakciók 
belsejében lehet beállítani a 


SET TRANSACTION ISOLATION LEVEL szint 


utasítással. Az utasítás hatására a tranzakcióban szereplő 
összes SELECT utasítás az adott elszigeteltségi szintnek 
megfelelően fogja olvasni az adatokat, illetve elhelyezni a 
zárolásokat a már olvasott adatokon. A tranzakció belsejé- 
ben bármikor át lehet térni más elszigeteltségi szintre, és 
onnantól kezdve a SELECT-ek annak megfelelően fognak 
működni. Ez azonban nem jelenti azt, hogy az előtte levő 
SELECT-ek által lefoglalt zárolások feloldódnának, csak azt, 
hogy az ezután kiadottak az új szintnek megfelelően fog- 
nak viselkedni. Igazából nem sok szituáció indokolja a szin- 
tek váltogatását egy tranzakció során, általában az elején 
beállítunk egy nekünk megfelelő szintet, és azt használjuk 
a tranzakció végéig. Lássuk hát a négy szintet! 


1. READ UNCOMMITTED (dirty read) 

Ezen a szinten a tranzakcióban szereplő utasítások bármi- 
lyen adatot kiolvashatnak a táblákból, függetlenül attól, 
hogy az adott sort/lapot/táblát zárolta-e valamely más fo- 
lyamat. Ez azt is jelenti, hogy olyan adatokat is olvashat, 
amik még nincsenek véglegesen lerögzítve az adatbázisba, 
azaz a módosító tranzakció végén még nem volt COMMIT 
TRAN, és lehet, hogy a következő pillanatban visszavonják. 
Másképpen fogalmazva fizikailag helyes adatokat fogunk 
kiolvasni, azonban logikailag nem biztos, hogy helyeset. 
Ez az elszigeteltségi szint üzleti tranzakciókban elfogadha- 
tatlan, hisz ott csak akkor fogadhatunk el egy adatot érvé- 
nyesnek, ha az őt beszúró vagy módosító folyamat véglege- 
sítette a változtatását. 

Azonban sokszor nem fontos az adatok hajszálra menő pre- 
cizitása, de fontos, hogy a tranzakciónk ne blokkoljon más 
tranzakciókat a sok és hosszú idejű kiolvasás által generált 
zárolásokkal, valamint, hogy a módosító tranzakciók ne aka- 
dályozzák a lekérdezésünk futását. Általában statisztikák és 
trendek analízise, kimutatások és összesített eredmények 
számolása során nem baj, ha beveszünk a számításba né- 
hány olyan sort, amelyek esetleg egy másodperc múlva már 
nem is léteznek, de cserébe gyorsan lefut a tranzakciónk. 
Ilyenkor nagyon jól jön ez az elszigeteltségi szint. 

Nézzük meg, hogy ezen a szinten egy SELECT hatására mi- 
lyen zárolások keletkeznek az adatbázisban: 


BEGIN TRAN 
SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED 


SELECT 
4. 
FROM 
Employees 
WHERE 
LastName LIKE "B8" 
EXEC sp lock E€GSPID 


COMMIT TRAN 


tech.net 


Kimenet: 
LastName FirstName 
Buchanan Steven 


(1 row(s) affected) 


spid dbid Objid  IndId Type Resource Mode Status 


A kimenetben csak azokat a sorokat hagytam meg, ame- 
lyek a 6-os dbid-jű adatbázisra vonatkoznak, ami a vizsgált 
Northwind. Mit jelent ez a kimenet? Az első zárolásokról 
szóló sor azt mutatja, hogy szerver elhelyezett egy Shared 
lock-ot a 6-os adatbázisra (Northwind) adatbázis szinten. 
Ezt csak azért tette, hogy a tranzakció alatt ne forgassák fel 
alapjaiban az adatbázist, ám semmi más zárolás nem látszik. 

Sajnos azt nem látjuk, hogy a kiolvasott sorokat még a 
SELECT lefutása idejére sem zárolta a szerver, mert mire 
a végrehajtás az sp lock-ra kerül, a zárolások (ha lettek vol- 
na) már rég megszűntek volna. Azt azonban könnyű megfi- 
gyelni a következő példában, hogy ezen a szinten lehet nem 
véglegesített (csúnya hunglish-el élve nem kommitált) lapokat 
olvasni, és hogy a SELECT nem vár az exkluzív zárolások miatt. 
Futtassuk le az alábbi kódot egy másik Ouery Analyzer ablakban: 


BEGIN TRAN 


UPDATE 
Employees 
SET 


LastName - "Borzaska! 


Azaz megkezdünk egy tranzakciót, amiben minden alkal- 
mazott családi nevét Borzaskára állítjuk. A tranzakciót lo- 
gikailag még nem véglegesítettük, ám a változások fizikai- 
lag már rögzítődtek a táblába. Mit lát ebből a korábbi le- 
kérdezésünk (READ UNCOMMITTED szinten)? 


FirstName 





Borzaska 


Borzaska 


Azaz látja a beírt, de még nem véglegesített adatokat! 
Ezért hívják dirty read-nek ezt a szintet. Viszont láttuk, 
hogy nem tudtuk megakadályozni az olvasást még egy 
egész táblára szóló UPDATE-el sem, azaz ezen a szinten 
az adatbázist olvasó műveletek nem foglalkoznak még az 
Exclusive lock-okkal sem. 

Hogy megnyugodjanak a kedélyek, görgessük vissza az 
előbbi félbehagyott tranzakciónkat: 


ROLLBACK TRAN 
2. READ COMMITTED 


Ez az alapértelmezett elszigeteltségi szint az SOL szerver- 
ben. Ezen a szinten a SELECT utasítások Shared lock-okat 
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helyeznek el azokon a sorokon, amelyeket éppen olvasnak. 
Emlékezzünk vissza, a Shared lock egy olyan zárolási típus, 
amit akárhányan olvashatnak, de senki nem írhat. Azaz a Sha- 
red lock megakadályozza, hogy valaki belenyúljon azokba az 
adatokba, amit a SELECT éppen olvas. Amint a megfelelő sor, 
lap vagy tábla kiolvasása megtörtént, a zárolások feloldód- 
nak. Amennyiben a SELECT halad előre a sorok olvasásával, és 
beleütközik egy Exclusive lock-ba, ami azt mondja neki, hogy 
állj, ne tovább, akkor kénytelen arra várni, hogy az Exclusive 
lock feloldódjon. Ellenkező esetben visszalépnénk az előző 
szintre, és olyan adatokat olvasnánk, amelyeket még nem 
véglegesítettek. Ez a szint azonban arról szól, hogy csak olyan 
adatokat olvashat az adatbázisból, amelyeket már véglegesí- 
tettek, innen a szint neve is. Azaz ezen a szinten logikailag 
mindig konzisztens adatokat olvasunk ki. 

Futtassuk le a korábbi teszt tranzakciónkat ezen a szinten is: 


BEGIN TRAN 
SET TRANSACTION ISOLATION LEVEL READ COMMITTED 


A tranzakciót egyedül lefuttatva a lekérdezés kimenete és a 
keletkezett zárolások pont úgy néznek ki, mint az előző 
szinten. Azonban gyökeresen más a helyzet, ha elindítjuk a 
másik ,zavaró" tranzakciónkat is. Azaz futtassuk le az ab- 
ban található UPDATE-et, de ne hajtsuk végre a ROLLBACK 
TRAN-t, hanem helyette indítsuk el az első lekérdezést! 
Mit látunk? Semmit. A lekérdezés csak fut, csak fut... Mi- 
vel a másik tranzakció adatmódosítása Exclusive lock-okat 
helyezett el a tábla sorain (sőt ez egész táblán, mert min- 
den sort módosítottunk), a SELECT ezen a szinten már fi- 
gyelembe veszik ezeket a zárolásokat, és addig nem haj- 
landó kiolvasni az adatokat, amíg a zárolás el nem takaro- 
dik a sorokról. Ehhez hajtsuk végre a ROLLBACK TRAN-t a 
második tranzakcióban! Ekkor az első tranzakció is befeje- 
zi a futását, és kiadja az eredeti, módosítás előtti sorokat: 
LastName FirstName 


Buchanan 


Amennyiben a második tranzakció nem visszagörgeti, ha- 
nem érvényesíti a tranzakciót COMMIT TRAN-al, természe- 
tesen akkor is folytatja a futást az első tranzakció SELECT- 
je, csak a már módosított adatokat olvasva. 

Ezen a szinten semmi nem biztosítja azt, hogy a tranzakción 
belül ugyanazokkal a feltételekkel visszaolvasva az adatokat 
ugyanazt az eredményt kapjuk két különböző időpillanatban. 
Lehet, hogy más tranzakció megváltoztatja az általunk kiolva- 
sandó sorokat a két kiolvasás között, ezt nevezzük nem megis- 
mételhető olvasásnak (non-repeatable read) . Az is előfordulhat, 
hogy beszúrnak olyan sorokat a két SELECT közötti időben, 
amelyek megjelennek a második SELECT eredményhalmazában. 
Ezeket a megjelent sorokat hívják fantomoknak (phantoms). A 
következő két szint ezeket a problémákat fogja orvosolni. 


3. REPEATABLE READ 

Itt már biztosak lehetünk abban, hogy logikailag helyes 
adatokat olvashatunk ki a táblákból, plusz, hogy egy 
tranzakción belül ugyanazt az olvasást többször megismé- 
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telve mindig ugyanazt az eredményt kapjuk vissza. Ezt azt jelen- 
ti, hogy a már olvasott sorok tartalma nem fog megváltozni, de 
nem jelenti azt, hogy nem jelenhetnek meg új sorok más 
tranzakciók ármány munkájának köszönhetően. Hogyan védeke- 
zik az SOL Server a már olvasott sorok módosítása ellen? Úgy, 
hogy a SELECT-ek által végigolvasott sorokra (lapokra vagy táblá- 
ra) elhelyezett Shared lock-okat nem oldja fel egészen a tranzak- 
ció végéig. Ezek után hiába akarja valamelyik másik tranzakció 
módosítani a már leválogatott sorokat, a Shared lock-ok nem en- 
gedik meg, hogy megtegye, egészen a tranzakció befejezéséig. 
Ezen a szinten már nagyon erősen érezhető a zárolások 
miatti párhuzamosság csökkenése, hisz egy 


SELECT t FROM tábla 


utasítással gyakorlatilag befagyasztjuk az összes olyan 
tranzakciót, ami a táblán akar módosítani. Azaz csak tény- 
leg olyankor érdemes bevetni, amikor a tranzakción belül 
többször ki kell olvasni ugyanazokat a sorokat, és fennáll a 
veszélye, hogy valaki közben módosítja őket. 

Ha megnézzük, milyen zárolások keletkeznek ezen a szin- 
ten, akkor a következőt látjuk: 


spid dbid ObjId Indid Type Resource Mode 
51 6 o o DB s 
51 6 1977058079 1 KEY (0500d1d065e9) s 
51 6 1977058079 2 KEY (6c0lb4ác53be8) S 
51 6 1977058079 1 PAG 1:136 Is 
51 6 1977058079 o TAB Is 
51 6 1977058079 2 PAG 1:385 Is 


Azaz a lock manager elhelyez Shared lock-okat sorokra a 
kulcsaikon keresztül (2. és 3. sor), valamint Intent Share 
lock-okat a lekérdezett sort tartalmazó lapokra (4. és 6. 
sor), valamint a táblára (5. sor). Az Intent Share jelzi más 
tranzakcióknak, hogy ne is próbáljanak Exclusive lock-ot 
kérni a kérdéses lapokra vagy az egész táblára, mert úgy- 
sem fog sikerülni, hisz az adott ,nagy" tartományokon be- 
lül vannak olyan sorok, amelyek Shared lock-kal védettek. 

Miért van két sor és lap zárolás, amikor a lekérdezés kimenete 
csak egy sort tartalmaz? Láthatjuk, hogy különböző indexekhez 
(Indid oszlop) tartoznak a zárolások. Az Employees táblán há- 
rom index is van, ezek közül kettőt használt a lekérdezés. A 
LastName-re szűrtünk, ehhez a LastName oszlopra definiált 
Nonclustered index-et használta a szerver (ez könnyen ellenőriz- 
hető a végrehajtási terv megtekintésével is). Miután megtalálta 
a LastName index táblában a megfelelő sorokat (jelen esetben 
1 sor), a Nonclustered index, mint sorazonosító segítségével 
kiolvassa a megfelelő sor tartalmát. Ahhoz, hogy biztosítsa a 
zárolást bármelyik indexet használó tranzakció elől, kénytelen 
zárolni mindkét index által lefoglalt sorokat és lapokat. 


4. SERIALIZABLE 

Nagyon hasonlít a REPEATABLE READ szintre, csak itt meg kell 
akadályozni azt is, hogy ugyanazt a SELECT-et megismételve 
új sorok jelenjenek meg az eredményhalmazban. Ehhez a szer- 
vernek le kell zárolni a teljes lehetséges tartományt, amelyet 
a SELECT WHERE feltétele jelöl ki. Az SOL Server a tartomány 
zárolására a már említett key-range lock-ot használja. 
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Nézzük meg az előbbi lekérdezést, aminek feltétel része a 
következő volt: 


WHERE 
LastName LIKE "B$8$" 


E szint logikájának megfelelően a szervernek le kell zárol- 
nia az összes olyan lehetséges index irányokat, amelyeken 
keresztül B betűvel kezdődő nevű sorokat be lehetne szúr- 
ni a táblába. Milyen zárolások generálódnak ennek érdeké- 
ben? (az objid oszlopot nyomdai okokból kihagytam) 


spid dbid Indid Type Resource Mode 
54 6 o DB s 
54 6 o TAB Is 
54 Ü. a PAG 1:99 Is 
54 6 2 PAG 1:97 Is 
54 6 KEY (7901573565c0) RangeS-S 
54 6 — 255 PAG 1:225 Is 
54 6 — 255 RID 1:225:12 s 
54 é a KEY (050041d065e9) S 
54 6 255 RID 1:225:11 s 
54 é KEY (6c01b4ác53be8) RangeS-S 


Látható, hogy a két RangeS-S (Shared Key-Range and Sha- 
red Resource) zárolás lezárta a LastName-re definiált 
Nonclustered index két végét (A és C betűvel kezdődő sorok 
közötti rész) , így oda nem lehet új sorokat beszúrni. 

A szintek tárgyalásánál nem szóltam az sp. lock kimeneté- 
ből az utolsó oszlopról. Abban látható, hogy a zárolást 
megkapta-e a kérő, vagy csak vár rá. Az összes példámban 
a mező értéke GRANT volt, azaz a kérő megkapta a zárolá- 
sát. A READ COMITTED szintnél az UPDATE tranzakció blok- 
kolja az olvasni kívánó tranzakciót, ilyenkor az utolsó osz- 
lopban WAIT olvasható, azaz vár arra, hogy a másik 
tranzakció feloldja az általa foglalt zárolást. 


Locking hints 

Többször hivatkoztam arra, hogy az SOL Servert lehet befo- 
lyásolni abban, hogy milyen típusú, és milyen finomságú 
zárolásokat helyez el a tranzakciók során érintett adatokon. 
Most jött el az ideje, hogy áttekintsük ezeket. 

A SELECT, UPDATE, DELETE és INSERT utasításokat ki lehet 
egészíteni egy WITH (hint) záradékkal, amely segítségével 
az SOL Servert el lehet téríteni az általa választott műkö- 
déstől, és így megszabhatjuk, hogy milyen index-et, záro- 
lást satöbbi használjon a táblák elérése során. Mi itt, most 
csak a zárolásokat befolyásoló hint-ekkel foglalkozunk. 

Az első csoport a zárolás finomságára vonatkozik. A ROW- 
LOCK arra utasítja a szervert, hogy a zárolandó sorok szá- 
mától függetlenül (még ha az egész táblára is vonatkozik) 
ne használjon nagyobb kiterjedésű zárolást, mint sor szin- 
tűt. Hasonlóan a PAGLOCK, TABLOCK lap illetve tábla szin- 
tű zárolás használatára kéri a szervert. 


Példa: 


SELECT t FROM Orders WITH (PAGLOCK) 
WHERE OrderID -— 1213 
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Az előbbi módosítók a zárolás finomságát állították. A kö- 
vetkezők a zárolás típusát szabályozzák. 

Az UPDLOCK segítségével a SELECT az alapértelmezetten 
használt Shared lock helyett Update lock-ot helyez el az ol- 
vasott táblán. Ennek előnye, hogy a már olvasott sorokon a 
tranzakció végéig megmarad az Update lock, így mások ol- 
vashatják az általunk kiolvasott sorokat, de nem módosít- 
hatják azokat. (Az Update és a Shared lock között annyi a kü- 
lönbség, hogy a már fennálló Shared lock-ra kiadható egy Up- 
date lock, de egy Update-re egy másik Update már nem.) 

Az XLOCK Exclusive lock-ot helyez el az adott utasítás által 
érintett sorokon. Azaz például egy ilyen módon átidomított 
SELECT képes exkluzívan zárolni egy egész lapot vagy táblát. 
A NOLOCK és a READUNCOMMITTED ugyanazt jelenti, azaz min- 
denféle zárolástól függetlenül felolvassa a kért adatokat. Ezt 
kiadva a tranzakció összes utasítására ugyanazt érjük el, mint 
ha a tranzakció elszigeteltségi szintjét az elején READ UNCOM- 
MITTED-re állítottuk volna. Gyakori felhasználás statisztikákban: 


SELECT OrderID, SUM(AmounttUnitPrice) 
FROM [Order Details)] WITH (NOLOCK) 
GROUP BY OrderID 


Azaz az Order Details táblán működő egyéb adatmódosító 
tranzakcióktól függetlenül, mindenféle zárolást kikerülve 
olvasunk adatokat. 

A HOLDLOCK és a SERIALIZABLE lock hint-ek hatására az 
SOL Server úgy kezeli az érintett táblákon a zárolásokat, 
mintha a tranzakció SERIALIZABLE módban lenne, azaz a 
Shared lock-okat nemcsak az olvasás idejére, hanem az 
egész tranzakció idejére fenntartja a már olvasott sorokon 
(innen a HOLDIock név). 

A READCOMMITTED hint a READ COMMITTED elszigeteltségi 
szint párja. Mivel ez az alapértelmezett szint, ritkán van 
szükség rá, hogy explicit kiírjuk. 

Hasonlóan a REPEATABLEREAD az azonos nevű izolációs 
szint párja. 

Az utolsó hint egy kicsit más, mint az előzőek. A READPAST azt 
mondja egy SELECT utasításnak, hogy egyszerűen ugorja át 
azokat a sorokat, amelyeket más tranzakció zárolt, és olvassa 
fel a nem zárolt sorokat. Ez csak READ COMMITTED elszigetelt- 
ségi szintű tranzakciókban működik, és csak a sor szintű záro- 
lásokat tudja átlépni. Egy adatbázis elmélettel foglalkozó em- 
bernek ettől égnek áll a haja, de a való életben vannak olyan 
helyzetek, amikor hasznos lehet ez a szolgáltatás. 

Azt írtam, hogy ezeket a hint-eket mind a négy alaputasí- 
tással lehet használni. Természetesen ez csak korlátozot- 
tan igaz, hiszen például a READPAST-nak nincs értelme az 
adatmódosító utasításoknál, azaz csak SELECT-el használ- 
ható. Mindegyik hint-nek megvan a maga logikája, és csak 
azokon a helyeken működik, ahol van értelme. 


Application lock-ok 

SOL Server 2000 újdonság az application lock-ok megjele- 
nése. Segítségükkel létrehozhatunk saját zárolási mechaniz- 
musokat a szerver lock manager-ének felhasználásával. Láttuk 
a zárolások finomságának tárgyalásánál, hogy a lock manager 
az igazából nem tud róla, hogy ő milyen objektumon végez 
zárolást (a nevét tudja, de a belső struktúrájáról semmit nem 
tud), csak van neki egy táblázata, amely alapján eldönti, hogy 
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az ütköző zárolás kérések esetén továbbengedheti-e az igény- 
lőt, vagy várakoztatnia kell, amíg elfogynak a konkurens zá- 
rolások. Most megkaptuk ezt a logikát, amely segítségével 
más programnyelveken megszokott kritikus szekciókat illetve 
szemaforokat valósíthatunk meg az alkalmazásainkban. 

Saját zárolás létrehozása nagyon egyszerű. Az sp getapp- 
lock tárolt eljárás meghívásával kérünk egy általunk megál- 
modott zárolási típust, egyedi néven. Elindítjuk a véden- 
dő, zárolandó eljárásunkat. Az eljárásunk lefutása után az 
sp. releaseapplock eljárással szabadíthatjuk fel a zárolást. 
Gyakori feladat például az, hogy egy tárolt eljárást egy- 
szerre csak egy felhasználó futtathat. Application lock-ok 
felhasználásával ezt nagyon egyszerűen megoldhatjuk: 


EXEC sp getapplock "SociLock", "Exclusive!", 


"Session" 
EXEC VédendőrároltEljárás 
EXEC sp releaseapplock "SociLock", "Session" 


Az sp. getapplock első paramétere a zárolás egyedi neve. A má- 
sodik paraméter a zárolás típusa, amit mi most Exclusive-ra ál- 
lítottunk, mert azt akarjuk, hogy miután valakinek sikerült túl- 
jutni a zároláson csak ő futtathassa a VédendőTároltEljárás-t, 
egészen addig, míg az sp. releaseapplock-al el nem engedjük a 
zárolást. A Session" azt jelenti, hogy ugyanarról a felhasználói 
kapcsolatról nem hatásos a zárolás, csak különböző kapcsola- 
tok között. Ez azt is jelenti, hogy ugyanaz a felhasználó több- 
ször is lefuttathatja a védett eljárást, mert a lock saját magá- 
ra hatástalan. Ha azt akarjuk, hogy még ugyanaz a felhaszná- 
ló se futtathassa többször a közbenső eljárást, akkor a Sessi- 
on" helyett Transactiorr-t kell írni, és a három eljáráshívást 
tranzakcióba (BEGIN TRAN, COMMIT TRAN) kell foglalni. Ekkor 
a zárolás tranzakciószintű lesz, így még egyazon felhasználói 
kapcsolaton futó párhuzamos tranzakciók is zárolják egymást, 
megakadályozva a párhuzamos futtatást. 

A Shared és az Exclusive és a többi zárolási típus variálá- 
sával kialakíthatunk más jellegű zárolási sémákat is, ame- 
lyek megfelelően támogatják az alkalmazásunk logikáját. 


Zárszó 

Cikksorozatunk eddigi legnehezebb része volt a zárolások 
témaköre. Ezután már általában könnyebb, gyakorlatiasabb 
részek jönnek. Úgyhogy az a kedves olvasó, akinek volt tü- 
relme végigolvasni és értelmezni a cikket (abban már csak 
reménykedni merek, hogy az esetleges kérdőjeles részek- 
hez előkerült a Books Online is), már megtette az első lé- 
pést abban az irányba, ami a professzionális adatbázis ter- 
vezés felé vezet. Az adatbázis zárolási eljárásának ismere- 
te nélkül tranzakciókat és adatbázisokat tervezni vakrepü- 
lés, amely előbb-utóbb egy sziklafalon végződik. 

A következő cikkbe szorult át a dead-lock-ok elmélete és 
gyakorlata, amely azonban csak a zárolások ismeretében 
érthető meg. Visszavárom Önöket a halálos ölelések szige- 
tén, a következő számban! 


Soczó Zsolt MCSE, MCSD, MCDBA 
Zsolt.Soczo(onetacademia.net 
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ASP suli 3. 


Bábeli zűrzavar 


Rengeteg levelet kaptunk, hogy az előző számban, a Session 
objektum ismertetése során méltatlanul kevés helyet szentel- 
tünk a CodePage és LCID jellemzőknek. A meglátás jogos, ezért 
most igyekszem bepótolni a kódtáblákkal, lokalizálással kap- 
csolatos információkat. Mint mindig, az aktuális példaprogra- 
mok természetesen letölthetők a [1] címről. 


Volt egyszer egy ASCII 

Az Internet használatának első éveiben, az aktuális feladatok 
megoldására a 7 bites ASCII kódolás tökéletesen elegendő volt. 
A 7 bitbe (127 karakter) belefért a teljes angol ABC, a számok 
és még néhány jel is. Azután a hálózat kezdte átlépni a hatá- 
rokat, és egyre inkább szükség volt az angoltól különböző nyel- 
vek betűinek megjelenítésére is. 

Eközben a hétbites rendszerekről lassan megkezdődött az átté- 
rés a nyolc bitre (így lett az ASCII-ből ANSI) , ezután kézenfek- 
vő volt, hogy a speciális karaktereket a megjelenő 128 üres 
helyre lehet bekódolni. Ahány ház, annyi szokás: ki így, ki úgy 
töltötte ki ezt a felső tartományt. A különböző megoldásoknak 
köszönhetően megszülettek a kódtáblák (codepage), és elkez- 
dődött a káosz. Még messze a DOS-os időkben járunk, amikor a 
táblázatrajzoló karakterek helyett néha ékezetes karakterek je- 
lennek meg a rossz beállításoknak köszönhetően. A nyugat-eu- 
rópai (westem) kódtáblák tartalmaznak ugyan ékezetes betű- 
ket, de a magyar hosszú ő és ű már nem fért bele. Sebaj, van 
hasonló: (sajnos) valószínűleg mindannyian találkoztunk már a 
kalapos ű és hullámos ő betűkkel. Akkoriban ez a kis csúsztatás 
még elviselhetőnek tűnt, manapság viszont már inkább kínos 
hibának tűnik a megjelenésük - teszem hozzá, jogosan. 

A világ ugyanis azóta sokat fejlődött. A szerteágazó kódtáblákat 
szabványokká fogták össze, a dokumentumokba beépítették a 
karaktertáblákat azonosító adatokat, így egy HTML oldal forrá- 
sából, vagy egy e-mailből azonnal kiderül, hogy azt a küldője 
milyen karaktertáblával írta. Bizony, így van ez akkor is, ha a 
(főleg nem Windows platformon futó) levelezőprogramok zöme 
erről nem hajlandó tudomást venni. Mindenekelőtt két fontos 
kódtáblára hívnám fel a figyelmet: az iso-8859-1, más néven 
Western kódtábla a nyugat-európai karaktereket (és a hullá- 
mos/kalapos 6-t és ú-t) tartalmazza, míg az iso-8859-2 alias 
Central European nevéhez méltón a számunkra oly kedves ma- 
gyar változatot. Hasonló hatást lehet elérni a Windows-1250 ne- 
vű kódlappal, ez azonban, mint az a nevéből is kitalálható, nem 
kifejezetten elterjedt Un"x és Macintosh körökben :-). Magyar 
szövegben, amikor csak tehetjük, használjuk az iso-8859-2-t! 


Speciális karakterek a HTML kódban 

Térjünk vissza kicsit a HTML és ASP mezsgyéjéhez. A HTML 
dokumentumokban a különleges karaktereket speciális mó- 
don, úgynevezett entity-k segítségével írták le. A (kalapos) 
hosszú ű kódja például gucirc; a (hullámos) hosszú ő pedig 
gotilde;. Sokan a mai napig használják ezt a kódolást, pe- 
dig egyrészt hosszú, kényelmetlen, másrészt pedig felesle- 
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ges. A böngészők már régóta képesek feldolgozni a külön- 
féle kódtáblákban írt HTML dokumentumokat - azokba pe- 
dig egyszerűen csak bele kell írni a betűket. 


Itt jegyezném meg, hogy bizonyos jeleket még mindig ér- 
demes entity-k segítségével leírni. Ilyen például a " (gtra- 
de;), a ? (8acopy;) ,az ? (8reg;), illetve a matematikai jelek, 
és más speciális karakterek (geuro; gyen; gfrac12; 8.sect;) . 
A [2] címen, a HTML 4 szabvány leírásán belül megtalálha- 
tó a szabványos entity-k teljes listája, de ezzel már bánjunk 
nagyon óvatosan, mert a böngészők eléggé hadilábon áll- 
nak az igazán speciális karakterekkel. 


Ha egy böngészőben megkeressük az Encoding vagy Charac- 
ter Set menüpontot, láthatjuk, hogy mely kódtáblákat ké- 
pes felismerni és használni. A HTML oldal kódjában pedig a 
készítő megadhatja a használt kódtábla azonosítóját, az ol- 
dal nyelvét, de ha ez elmarad, akkor is van rá esély, hogy a 
böngésző helyesen ismeri fel azt. 


Árvíztűrő tükörfúrógép 

Tegyünk hát egy próbát! A fenti mondat tartalmazza az 
összes speciális magyar betűt, (ízetlen tréfa következik, de 
nem tudom kihagyni: szegény tisza-menti üvegeseknek már 
biztosan van ilyen...) , amit az arviz1.htm oldal kódjába ne- 
mes egyszerűséggel, kódolatlanul beleírtunk: 


chtml. 
cheadPc/head5 
cbodyz2 
árvíztűrő tükörfúrógép - ÁRVÍZTŰRŐ TÜKÖRFŰRÓGÉP 
£/body2 
€/htmiz 


Ha ezt az oldalt megjelenítjük, a böngésző a kódtábla megadása 
híján megpróbálja felismerni a használt változatot. Ha úgy dönt, 
hogy nyugat-európai kódolást választ, jönnek a kalapos ékeze- 
tek. (Az éppen használt kódtáblát az Encoding menüben láthat- 
juk kiválasztva. Ha ezt kézzel módosítjuk, a kódolás helyreáll.) A 
találgatások elkerülése érdekében a böngészőt kifejezetten utasít- 
hatjuk egy adott kódtábla használatára, emígyen (arviz2.htm): 


chtml: 
ZXhead: 
Smeta http-eguiv-"Content-Type" 
hl content-"text/html; charset-iso-8859-2"5 
€/headz 
Lbody2 
árvíztűrő tükörfúrógép - ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP 
£/body2 
€/htmli5s 
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A lényeg az aláhúzott sorban, az úgynevezett Content-Type fej- 
lécben van, ahol nemcsak az oldal HTML mibenlétét határozzuk 
meg, hanem a használt kódtáblát is. Akinek ismerős ez a sor, 
jól téved: néhány hónappal ezelőtt, a Response.Charset jel- 
lemző leírásánál már megemlítettük. Ha azt használjuk, 
ugyanezt a hatást érjük el, miközben az ASP oldalon belül el- 
kerülhetjük a META elem használatát (arviz3.asp): 


c$ Response.Charset - "iso-8859-2" 85 
Xchtmli2 
chead:c/head: 
cbodyz 
árvíztűrő tükörfúrógép - ÁRVÍZTŰRŐ TÜKÖRFÚRÓGÉP 
£/body2 
€/htmlz 


További META elemek 
Ha már itt tartunk, felsorolnék néhány, eddig még nem emlí- 
tett hasznos metainformációt, amit a weboldalakba ágyazva 
különféle hatást érhetünk el. 
LxMETA name-"author" content-"Fülöp Miklós"5 
CxaMETA namez"date" contents"03/07/01"5 
LcxcMETA namez"description" content-"ASP Suli 3"5 
LxMETA name-r"keywords" content-"ASP, learning"5 
CMETA names"robots" content-"noindex, nofollow"5 


LKMETA http-eguiv:"Content-Language" content-"hu"5 


A fenti információk nagy része egyelőre igazán csak a webes 
keresők számára érdekes. Az author (szerző), date, keywords, 
description mezők tartalmát a jobb keresők feldolgozzák, ke- 
resés során a keywords mezőben megjelenő kulcsszavak pél- 
dául nagyobb súllyal bírnak, mint a dokumentum szövegéből 
kivonatolt minta. A description mező értékét a keresésre adott 
válaszban szokás megjeleníteni. Ha oldalunk tartalmaz ilyen 
mezőt, akkor a rövid leírás nem a dokumentum első néhány 
sora lesz, hanem a description-ként megadott szöveg. 

A robots metaelem a keresők felderítő-egységeinek (ezek a 
robotok) működését szabályozza, a noindex érték arra uta- 
sítja a robotot, hogy az oldalt ne indexelje, ne tárolja az 
adatbázisba, a nofollow pedig azt jelenti, hogy az oldalon 
található hivatkozásokat nem kell követni. A legfontosabb 
mégis a Content-Language, ami. nem is metainformáció, 
hanem HTTP fejléc. Értéke a dokumentum nyelvére utaló 
rövidítés, magyar esetén természetesen a ,hu" (a további 
kódok megtalálhatók például itt: [4]) 


Vissza a kódtáblákhoz 

A különféle kódtáblák használata azonban nem oldott meg 
minden gondot. Nem nagyon használhatunk egy dokumentu- 
mon belül több kódtáblát (a HTML codepage fejléc az egész do- 
kumentumra vonatkozik). Ennél is nagyobb gond az, hogy a 
legtöbb távol-keleti nyelv többezer különböző karaktert tartal- 
maz, ezt pedig nehezen lehet leírni egy 8 bites azonosítóval. 
Ezeken a területeken természetesen 16 bites kódtáblák alakul- 
tak ki, ahol egy jelet két bájt határoz meg. Persze ilyen kód- 
táblából is több fajta létezik, ezért kézenfekvő volt, hogy a 
kódtáblák közötti káoszt szabályozni kell. 

Több vezető számítástechnikai, informatikai cég, nyelvészek, 
könyvtárosok szervezetei, és még sokan mások ezért megala- 
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pították a Unicode Consortiumot. A szervezet célja az volt, 
hogy olyan szabályrendszert dolgozzanak ki, amivel végre egy- 
ségesen le lehet írni a világon beszélt (és már vagy még nem 
használt) összes nyelv minden karakterét, grafikai szimbólu- 
mokat, nyelvi elemeket. A Unicode szerint is minden karaktert 
két bájt azonosít, így 65535 különböző jel leírására van lehe- 
tőség. A táblázat még napjainkban is frissül, sőt, van olyan te- 
rülete is, ahova mi magunk definiálhatunk karaktereket (a 
0xE000-tól OxF8FF-ig). Ha van kéznél egy Windows 2000, tes- 
sék csak bepötyögni a Run ablakba: eudcedit.exe! 

A Unicode azonban nem kódolási szabvány. A karakterek két- 
bájtos értékét többféleképpen is felhasználhatjuk a dokumen- 
tumokban. Többféle kódolási mód terjedt el, természetesen 
mindegyik alapja maga a Unicode táblázat. Az egyik módszer 
szerint a dokumentum minden egyes karakterét két bájton áb- 
rázolják, ezzel természetesen megduplázva a méretét. Az alter- 
natív kódolási módok közül az UTF-7 és az UTF-8 terjedt el, 
ezek közül az UTF-8 lett a gyakoribb. 


Az UTF-8 kódolás 
Kódolás, és nem kódtábla, hiszen itt már szó sincs tábláról. 
Kódtáblaként maga a Unicode funkcionál. Lássuk, mit tud az 
UTF-8. Ebben a kódban egy karakter kódjának hossza 1 és 3 
bájt között mozog. Az ASCII karaktereket, tehát az első 127 
jelet hagyományosan, egy bájton kezeljük. Ennek köszönhető, 
hogy az UTF-8 dokumentumok, ha nem tartalmaznak túl sok 
extra karaktert, emberi szemmel még jól olvashatók. 
A 128 feletti értékek már nem férnek el egy bájton, ezért azok 
esetén már hosszabb leíróra van szükség. 
De álljunk meg egy pillanatra! Miért nem fér bele az első bájt- 
ba 255 karakter? Hát azért, mert akkor nem tudnánk megkü- 
lönböztetni a 0x6161-es kódot a 0x61 0x61-től. Ezért aztán, 
ha egy UTF-8 bájt értéke: 
"1 0x00-OX7F: az egybájtos ASCII karakter kódja 
0 0x80-OXBF: több-bájtos érték további bájtjai 
B 0xC2-OxDF: kétbájtos érték első bájtja 
I 0xE0-OxEF: hárombájtos érték első bájtja 
Tehát minél , messzebb" van a Unicode táblában egy karak- 
ter, annál hosszabban kell leírni (de legfeljebb három báj- 
ton). Ha egy karakter kódja 
-R. 0x0001-OxO07F, akkor 1 bájt (0x01-Ox7F) 
"7 0x0080-OXO7FF, akkor 2 bájt (OxC280-OXDFBF) 
"7 0x0800 felett, akkor 3 bájt (OXEOAO80-OXEFBFBF) 
A távol-keleten tehát az UTF-8 kódolás kicsit pocsékoló, hiszen 
ott a legtöbb használt karakter az utolsó tartományba esik. A 
világ nagy részén viszont, ahol az írás alapját valahol mégis- 
csak a latin betűk képezik, az UTF-8 sok helyet megspórol. 
Mutatok egy példát, kép formájában, mert ez már nem biz- 
tos, hogy túlélné az amúgy is rapszodikus nyomdai konver- 
ziókat :-). Íme: 

Zj utfö.txt - Notepad B -zIDI21 
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CS 91 
CE A9 


ES (88 92 
EF AD BB 


a Néhány karakter és UTF-8 kódja 
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Talán feltűnt, hogy milyen speciális alkalmazással hoztam 
létre ezt a dokumentumot. Nem csalás, nem ámítás, a Win- 
dows 2000 Notepad nevű csodaalkalmazása úgy nyeli a Uni- 
code karaktereket, mint kacsa a nokedlit. Kínaiul akarunk 
írni? Tessék! UTF-8 formátumban szeretnénk menteni? Tes- 
sék! (Vessünk egy pillantást a mentés menüre, ott van az En- 
coding mező!) . Teheti mindezt azért, mert a Windows 2000 
belül Unicode. (Itt kérnék elnézést, ha az utolsó két sor va- 
lamelyikében véletlenül egy japán vagy arab káromkodást 
idéztem volna, esküszöm, nem volt tudatos :-) ) 

A kódtábla-hegyek használatához mindössze egy dolgunk 
van: a Control Panel / Regional Settings dialógus General 
ablakának alján pipálgassuk be a megcélzott területeket, és 
némi telepítgetés után birtokunkba vehetjük a teljes Uni- 
code univerzumot. (Ha szeretnénk kipróbálni a többnyelvű 
ASP példákat, akkor most tegyük is meg!) . 


Lokalizálás 

Lokalizálás alatt nem csak az adott ország vagy nyelv betű- 
készletének használatát értjük, hanem sok minden mást is. 
Néhány példa, a teljesség igénye nélkül: dátumformátum, 
hónapok, napok nevei, 12/24 órás időszámítás, AM/PM he- 
lyi elnevezése, a dátum és idő elemeit elválasztó karakte- 
rek, az elemek sorrendje, a fizetőeszköz jele és írásának 
módja, a számok írásának módja, a számjegyek csoportosí- 
tása, a csoportosításra szolgáló jel, a tizedesjel, a hét első 
napja, a használt naptár, a sorbarendezés alapja, satöbbi. 
Minderre fel kell készülnünk, amikor lokalizált alkalmazást ké- 
szítünk, és nincs ez másképp az ASP alkalmazások esetén sem. 
A Windows teljes mértékben támogatja ezeket a lokalizá- 
ciós megoldásokat, ezért tulajdonképpen nincsen nehéz 
dolgunk. Maga a Windows is a Regional Settings lokalizá- 
ciós beállításai alapján működik, így jelennek meg a dátu- 
mok, időpontok, számok, de még a numerikus billentyűzet 
x." gombjának jelentése is (magyar beállítás esetén ugyanis 
- helyesen - nem tizedespontot, hanem tizedesvesszőt ír). 
A VBScript is számos hasznos funkciót tartalmaz [3]. A Get- 
Locale() függvény például meghívása után visszaadja a szá- 
mítógépen használt alapértelmezett beállítás kódját (a kód 
értelmezését lásd itt: [4]), a SetLocale() segítségével pedig 
beállíthatunk egy más értéket. Ha az adott nyelv támoga- 
tása nincs telepítve, a SetLocale() meghívása hibát okoz. A 
FormatCurrency(), FormatDateTime(), FormatNumber(), For- 
matPercent() függvények pedig az éppen érvényes beállí- 
tásnak megfelelően készítik el a fizetőeszköz, dátum és idő, 
szám és százalékértékeket (szöveges formában, persze). 

A locale.asp példaprogram segítségével kicsit játszadozha- 
tunk a beállításokkal. 


Weblapok UTF-8-ban 

Miután kigyönyörködtük magunkat a lokalizált adatok nézege- 
tése során, vegyük sorra, mi kell ahhoz, hogy valódi nemzetkö- 
zi oldalakat hozhassunk létre. 

Mindenekelőtt, a böngészőt utasítani kellene, hogy használjon 
valami értelmes kódtáblát. Természetesen minden nyelvhez 
megvan a saját kódtábla, de most univerzális megoldást kere- 
sünk, sőt, a végén egy oldalon belül több nyelv is megjelenik 
majd, ezért a választásunk természetesen az UTF-8-ra esik. He- 
lyezzük el a megfelelő META elemet az oldal fejlécében: 
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cmeta http-eguiv-"Content-Type" 
4 content-"text/html; charset-utf-8"5 


Ezután már csak arra kell ügyelnünk, hogy az oldal forráskódját 
is UTF-8, ban mentsük el, különben a böngésző el fogja nyelni 
az ékezetes karakterek után következő betűket (hiszen két- vagy 
hárombájtos értéket vár), valahogy így: 


Alhttp://localhost/asp3/bad1.htm - Microsoft interméti 

] File Edt View  Favorites Tools Help 
15-2-GAalansi5- aa -ATHU- ! 
J Address [E] http://docaihostjasp3/badt .htm . c] 








Ezti ! nik, amikor a beDDtt kOOugyan UTF-8, 
de az oldal tartalma nem UTF-8-ban ki§ " " 
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0 , Ez történik, amikor a beállított kód ugyan UTF-8, de az 
oldal tartalma nem UTF-8-ban készült." 


Ha a fenti példa megtekintése esetén a böngészőben kiválaszt- 
juk a Central European dekódolást, meglátjuk, hogy a doku- 
mentum valójában nem UTF-8-ban készült, de a böngésző en- 
gedelmeskedik a benne található META parancsnak. 

UTF-8 kódolású oldalt többféleképpen is előállíthatunk: 
mindenekelőtt, ha a webszerkesztőben a HTML Encoding ér- 
tékét Multilingual (UTF-8) -ra állítjuk. Egy alternatív lehető- 
ség, hogy elkészítjük a komplett oldalt, ahogy nekünk jól 
esik, majd a Windows 2000 Notepad-jával megnyitjuk, és 
visszamentjük UTF-8 formátumban. 


Az ASP által használt kódtábla beállítása 

Az rendben van, hogy mi már tudunk UTF-8-ban írni, de az ASP- 
nek is meg kellene valahogy magyarázni, hogy mit szeretnénk, 
különben a rendszer alapértelmezett kódtábláját használja. Er- 
re rögtön két lehetőségünk is adódik, egyrészt, használhatjuk a 
Session.CodePage jellemzőt, másrészt pedig a (OCODEPAGE ASP 
direktívát. Az UTF-8 kódolás ,kódtáblájának" azonosítója 
65001. Az alábbi két példa egyenrangú, de a Session.CodePage 
használata felülbírálja a direktívában meghatározott értéket: 


-C£$8 CODEPAGE-65001 85 
cz 

Session.CodePage - 65001 
32 


A kódtáblához hasonlóan természetesen a lokalizációs beál- 
lításokat is tudjuk módosítani. Mint a kódtáblánál, az ASP 
a számítógép alapértelmezése szerint lokalizál, de ez is 
megváltoztatható. Itt is két lehetőségünk adódik, a direk- 
tíva és a jellemző beállítása: 


C8A LCID51038 35 
cz 
Session.LCID - 1038 " Hungary 


82 
Ne feledjük, az ASP direktíváknak az ASP oldal tetején kell el- 


helyezkedniük, egynél több direktíva esetén egy sorban, egy- 
más után, így: 
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4238 CODEPAGE-65001 LCID-1038 35 


Mint azt már említettem, nemlétező, vagy nem támogatott 
kódtábla és lokalizációs beállítások használata hibát okoz. A 
hiba akkor lép fel, amikor a Session.CodePage illetve Sessi- 
on.LCID rossz értéket kap. Mi azonban nem szeretnénk, hogy 
az oldal végrehajtása hibával befejeződjön, sokkal jobb lenne 
valami intelligens hibakezelési megoldás. 


Hibakezelés az ASP oldalban 

A hibakezelés már nem az ASP környezet, hanem a scriptmo- 
tor feladata, ezért ahány scriptkörnyezet, annyi megoldás lé- 
tezik. Míg a Jscriptben a C programozóknak ismerős try/catch 
párost használhatjuk a hibák elfogására és kezelésére, addig 
VBScriptben a Visual Basic hibakezelési megoldása képezi az 
alapokat. A VBScript annyiban különbözik a VB-től, hogy itt 
nem definiálhatunk hibakezelő szubrutint. Az egyetlen, amit 
megtehetünk, az, hogy utasítjuk a scriptmotort, hogy hiba 
esetén ne álljon meg, hanem ugorjon a következő sorra, és 
majd mi kezeljük a hibát - ha akarjuk. Ezt a parancsot a kö- 
vetkezőképpen adhatjuk ki: 


et 
On Error Resume Next 
:! csináljunk valamit, ami hibát okozhat 
If Err.Number €5 0 Then " hiba történt 


Response.Write("HIBA! Kód:" § Err.Number) 


Response.Write("Leírás:" § Err.Description) 
Err.Clear 
End If 


sz 


A program futása során bármikor ellenőrizhetjük az úgyneve- 
zett Err objektumot. Ha az Err.Number értéke 0, nem történt 
hiba, ha attól különböző, akkor a hibakódot tartalmazza. 
Ilyenkor az Err.Description a hiba leírását adja vissza. Miután 
lekezeltük a hibát, töröljük azt az Err.Clear() metódus segít- 
ségével, különben a következő ellenőrzéskor is elkapjuk majd. 
Az IIS5 ennél fejlettebb hibakezelési eszközöket is tartalmaz 
(ott van például az ASPError objektum), de erről majd csak a 
következő számunkban ejtünk szót. 





Bábel tornya 

Fogjuk tehát az összes elérhető lokalizációs variációt, és írjuk 
ki egy oldalra az aktuális dátumot, időpontot és pénznemet! 
Az lcid.asp kódja a leírtak alapján teljesen érthető kell, 
hogy legyen. Az lcdemo.asp funkcionalitásában megegye- 
zik az lcid.asp-vel, csak kevesebb példát hoz. 


A cikkben szereplő URL-ek: 


[1] http://technet.netacademia.net/feladatok/asp/3 
[2] h Www.w3.O! html40/sgml/entities.html 
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Arabic - U.A.E. farag, LCID: 14337). 
Aratic - Algeria (ar-dz, LC! 
Arabic - Egypt (ar-eg, LCII 
Arabic - 

Arabic - 
Arabic - 


Czech (cs, LCID: 1029): 100 Ké 1 
Engich - United Kingdom (en-gb, LCI 
Englieh - United States (en-us, LCI 
Para (fa, LCID: 1065): 5 
Greek fel, LCID: 1032). 





Koran (ko, LCID: 1042): 
Macedonian (mk, LCID: 1071): 
Thai (th, LCID: 1054): 1.00 
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a Bábeli zűrzavar, de oly kedves a szívemnek. Hol van már 
az ASCII karakterkészlet? Érdemes megfigyelni, hogy az arab 
nyelveknél még az írás iránya is megváltozott! 


Valami elkezdődött 

Most mondhatná azt az olvasó, hogy könnyű a Microsoftnak. 
Könnyű a saját webkiszolgálót és böngészőt összehangolni. De 
nem erről van szó: az előállított oldal igenis szabványos, csak 
a szabványok megvalósítására kellene egy kicsit odafigyelni. 
Próbaképpen ránéztem a fenti oldalra alternatív böngészőkkel 
is (A képernyőképek letölthetők a [5] címről.) Az UTF-8 kódo- 
lást mindegyik böngésző felismerte, ahol tudta, megjelenítette 
az ékezetes karaktereket, és nem okozott gondot, hogy néhány 
karaktert több bájton ábrázoltunk. A versenyt az Opera 5.01 ve- 
szítette el, a megjelenített oldal tele van kérdőjelekkel - az 
arab, a cirill, a görög és a távol-keleti karakterek egyike sem 
látszik. A Netscape 4.61 már jobb eredményt produkált: csak 
néhány távol-keleti karakter helyett láthatunk csinos kis négy- 
szögeket. Kellemes meglepetés, hogy az új Netscape 6.01 
Gecko motorja ötös alát kapott: csak azért nem kitűnőt, mert 
nem vett tudomást az arab szöveg írásirányának megváltozásá- 
ról (a speciális vezérlőkarakterek pedig ott voltak a szövegben). 


Fontos! 
A helyes működés érdekében az IIS kiszolgálóra és az ügyfelek 
számítógépére is telepíteni kell a megfelelő nyelvi támogatást! 


Összefoglalva azt mondhatjuk tehát: itt az ideje, hogy elbú- 
csúzzunk a hullámos és kalapos ű és ő betűktől. A modern bön- 
gészők segítségével gyakorolhatjuk, hogy írják a kuszkuszt ere- 
detileg, saját nyelvén kívánhatunk boldog születésnapot thai 
barátnőnknek, Pandacsöki Boborján pedig immáron áttérhet 
az urdu nyelv írásos vetületére. :-) 


Fülöp Miklós 
mick Onetacademia.net 


[3] http://msdn.microsoft.com/scripting/vbscript/doc/vbstoc.htm 
[4] http://msdn.microsoft.com/scripting/vbscript/doc/vsmsclcid.htm 


[5] http://technet.netacademia.net/feladatok/asp/3/pic 


ASP objektummodell-referencia a weben: 


http://msdn.microsoft.com/librai 
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sdk/iisref/vbob7Zá4ábw.htm 
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Bevezetés 

A cikk célja, hogy megadja a kezdő lökést azoknak, akik már 
ismerik az XML nyelv alapjait, hallottak a hagyományos 
többrétegű alkalmazásfejlesztésről, de még nem használták 
ki alkalmazásaikban az XML-ben rejlő lehetőségeket. 

Az első részben végigfutunk az XML nyelv alapjain, a továb- 
bi részekben pedig konkrét gyakorlati példákon keresztül 
megnézzük, hogyan lehet kihasználni az XML előnyeit WEB 
fejlesztésekben. 


XML alapok - turbó sebességgel 

Hogy a gyakorlati részben pontosan lehessen követni a progra- 
mok és az XML kapcsolatát, megpróbálom tömören, de precízen 
definiálni az XML technológiában alkalmazott fogalmakat. 

Az XML nyelv egy olyan leíró nyelv, amely segítségével ada- 
tokat reprezentálunk. Úgy van megalkotva, hogy használ- 
hatjuk akár önleíró módon, akár egy előre meghatározott 
szabályrendszerre (séma) épülve. Ez utóbbi azt jelenti, 
hogy az adatok ábrázolásának struktúráját megköthetem 
előre, és csak azokat az XML dokumentumokat fogadom el 
megfelelőnek, amelyek az általam definiált szerkezet, séma 
alapján vannak megszerkesztve. 

Az XML nyelv alapelemei a tagok (tag). A tag egy , kacsacsőrök" 
a közé zárt szöveg. Például a cmalacs egy tag. Az XML tagok 
érzékenyek a kis-nagybetűre, cegérs és cEgérs nem ugyanaz! 
Az adatokat egy kezdő és egy záró tag közé kell elhelyezni, 
és az így nyert formációt XML elemnek (element) hívjuk. A 
záró tag ugyanolyan, mint a kezdőtag, csak egy / (per) jel 
van a tagban található szöveg előtt. Kezdőtag: cmalacs, 
záró tag: c/malacs. Így egy teljesen szabályos XML elem: 
cmalacsMazsolac/malacs 

A tagok között levő adatokat az elem értékeként (value) 
kezeljük. Az XML tagoknak tetszőleges számú attribútumo- 
kat (attribute) is adhatunk. Ezek név-"érték" típusú érték- 
adások. Az idézőjelek kötelezőek. Például, minden malac- 
hoz írjuk oda a legjobb barátját egy attribútumként: 
malac barát-"Manócska"sMazsolac/malacs 

Az XML dokumentum egy olyan XML elem, amelyben lehetnek 
beágyazott XML elemek. Tehát egy szem XML elem is már egy 
XML dokumentum, de a tipikus XML dokumentum több szin- 
ten is egymásba ágyazott XML elemekből áll. Például: 


cmesék: 

Zmesez 
SccimpxMazsolac/cim: 
cszereplozMazsolac/szereploz 
gszereplosManócskac/szereplos 
SszereplorTádéc/szereploz 

€/meses 

LZmeses 
dcimpPFutrinka utcac/cim: 


SszereplosBuksic/szereplo2 
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SszereplozMorzsic/szereplo2 
SszereplorCicamicac/szereplo?z 
£/mesez 


£/mesék: 


Az iménti példa egy jól megformázott (well-formed) XML 
dokumentum. Hogy miért? Egy jól megformázott XML doku- 
mentumnak teljesíteni kell a következő kritériumokat: 

"0 A kezdő és a záró tagoknak egyezniük kell 

"B Az elemek nem lapolhatják át egymást 

"8 A problémás karaktereket kódolni kell (c,8,5,",") 

"0 Kelllennie egy és csakis egy gyökér elemnek 
Tulajdonképpen egy jól megformázott XML dokumentum 
nem más, mint egy olyan dokumentum, ami illeszkedik az 
XML szabvány által specifikált szabályokhoz. 

Mitől lesz egy XML dokumentum érvényes (valid)? Attól, hogy 
nemcsak jól megformázott, hanem egy előre definiált sémának 
megfelelően van felépítve. Másképpen fogalmazva megkötöm, 
formálisan leírom az általam használni kívánt XML dokumentum 
nyelvét, és megnézem, hogy ennek a nyelvnek megfelelő-e a ka- 
pott dokumentum. Ha igen, akkor érvényesnek könyvelhetem el. 


Névterek 

Vágjunk bele egy kicsit bonyolultabb dologba, egy példán 
keresztül. Mi van akkor, ha több ország iskoláiból kapunk ta- 
nulmányi eredményeket (természetesen XML formátumban), 
és ezeket szeretnénk egy nagy XML dokumentumba foglalni? 
Azonban az egyik országban az 1-esnek örülnek a gyerekek, 
míg nálunk (legalábbis a legtöbb) az 5-ösnek. Ha egyszerűen 
összefűznénk az adatokat, akkor lehetetlen lenne összeha- 
sonlítani a különböző eredményeket. Valahogyan definiálni 
kellene az összesített XML dokumentumban a számok kétfé- 
le értelmezését. Ezután minden tételnél megjelöljük, hogy 
melyik tétel melyik értelmezéshez kapcsolódik, így később 
egyértelműen kibányászhatók az érdemjegyek. Az ilyen jel- 
legű problémák feloldására vezették be a névtér (namespa- 
ce) fogalmát az XML szabványban. A dokumentum elején 
meghatározzuk a leírni kívánt típusokat, és a tagoknál meg- 
jelöljük, hogy azok melyikhez tartoznak. Névtér használata 
nélkül így nézne ki az összevont érdemjegy táblázat: 


sosztályzatok: 
Soszt:4c/oszt: 
Soszt52c/oszt: 


c/Osztályzatok: 
Melyiknek örülne egy gyerek? Az attól függ, hogy honnan 
kerültek bele az adatok. Tegyük egyértelművé az adatok ér- 


telmezését: 


cosztályzatok 
xmlns:AzötösaJó-"http://iskola.hu/ot" 
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xmlns:AzEgyesaJó-"http://iskola.hu/Egy" 2 
SLAzötösaJó:oszt24c/AzötösaJó:oszt? 
ScAzÖtösaJó:oszt:5c/AzötösaJó:oszt: 
dcAzEgyesaJó:oszt:2c/AzEgyesaJó:oszt?2 


c/Osztályzatok: 


Mit láthattunk itt? Készítettünk két névteret. Az egyiknek 
,AzÖtösaJó", a másiknak AzEgyesaJó" a neve. A nevek tet- 
szőlegesen választhatók, lehetne Jancsi és Juliska is, de nem 
árt, ha a választott névtér neve utal a funkciójára. Az 
xmlns:névtérnév-"valami egyedi" segítségével definiálhatunk 
névteret egy taghoz. A , valami egyedi"-nek az egész világon 
egyedinek kell lenni, így elvileg a világ összes XML dokumen- 
tumát konfliktus nélkül össze lehetne fűzni, mert a , valami 
egyedi" egyértelműen azonosítja a forrást, így nem lehetnek 
névütközések. A névtérnév egy álnév (alias) a hosszú, egyedi 
névtér névre. Így a tagokban könnyebb rájuk hivatkozni. 

A névtér öröklődik, így a gyermek tagok (mint az oszt) is 
használhatják a szülőben (Osztályzatok), nagyszülőben, 
dédszülőben, satöbbi definiált névteret. 

Mit jelent az a bűvös URL a , valami egyedi" helyén? Ha 
beírom az Internet Explorerembe, akkor mi fog ott bejön- 
ni? Kakukkos óra? Nem, általában semmi! A névtér miről is 
szól? Arról, hogy valamilyen módon egyedi neveket kell 
definiálni. Erre két módszer adódik kézenfekvően: használ- 
junk valamilyen URL-t, vagy alkalmazzuk a Windows-os 
GUID-ot (Globally Unigue Identifier). Mivel a W3C konzor- 
cium, az XML gazdája nem csak a Microsoft által befolyá- 
solt szervezet, ezért a legtöbb névtér deklarációban URL-t 
látunk, és nem GUID-ot, mint egyedi névtér azonosítót. 
Amikor egy program feldolgozza az így összesített adato- 
kat, akkor minden egyes tag feldolgozása során megnézi, 
hogy az adott tag melyik névtérhez tartozik. A névtereket 
tudnia kell előre ahhoz, hogy tudja a dokumentumban ta- 
lálható számok, mint osztályzatok értelmét. Mivel a névtér 
garantáltan egyedi, azért a programunk értelmezni tudja a 
bejövő XML adatokat. Látni fogjuk, hogy konkrét termékek, 
például az SOL Server 2000 vagy az XML Parser XSL konver- 
tere csak akkor működik helyesen, csak akkor végzi el a 
kért műveletet, ha a névteret az előírtnak megfelelően, ka- 
rakterről-karakterre pontosan adjuk meg. 

Ha az adatok zöme egyféle értelmezésű, így csak egy kis 
százaléka kellene, hogy valami más névtérbe tartozzon, ak- 
kor érdemes kihasználni az alapértelmezett névtér (default 
namespace) lehetőségét, hogy rövidebb dokumentumot 
kapjunk. Ha az előbbi példánk bejövő adathalmazában a 
hazai (az ötös a legjobb jegy) értelmezés a leggyakoribb, 
akkor tegyük azt az alapértelmezett névtérré, így csak azo- 
kat az adatokat kell megjelölni, amelyeket nem így kell ér- 
telmezni. Az alapértelmezett névteret úgy deklaráljuk, 
hogy nem adunk álnevet a kívánt névtérazonosítónak: 


cosztályzatok 
xmlns-"http://iskola.hu/ot" 
xmlns:AzEgyesaJó-"http://iskola.hu/egy" 5 
goszts4c/oszt: 
£oszt35€/oszt: 
SxAzEgyesaJó:oszt:2c/AzEgyesaJó:oszt? 
£/Osztályzatokz 
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Kivételek persze mindig vannak. A névtéröröklődési láncot 
megszakíthatjuk bármely ponton úgy, hogy egy üres névtér- 
definíciót alkalmazunk a gyermekelemre, és attól a szinttől 
lefelé már nem lesz érvényes az alapértelmezett névtér: 


cOsztályzatok 
xmlns-http://iskola.hu/ot 5 
Soszt xmlnsz""5 
£01/5 
£02/5 
S/oszt: 
Soszt35c€/oszt: 


£/Osztályzatokz 


A példában a "http://iskola.hu/Ot" alapértelmezett névte- 
ret kapcsoljuk ki az első cosztz elemre, és az ő 2 gyerme- 
kére (c01/5 és c02/2). 

Fontos, hogy az alapértelmezett névtér nem vonatkozik az 
attribútumokra, csak a tagokra, azaz az coszt megj-"Okos 
gyerek"2 esetén a megj attribútum az nem tartozik az 
alapértelmezett névtérhez (semmilyen névtérhez sem tarto- 
zik). Ha azt szeretnénk, hogy ahhoz tartozzon, akkor min- 
den egyes attribútum elé is ki kell írni a névtér előtagot: 
oszt AzEgyesaJó:megj-"Okos gyerek"5. Ezzel még sokszor 
fogunk találkozni az adatbázis-XML kapcsolatok leírásánál. 


A fegyvertárunk 

Cikksorozatunk további részeiben elmélyedünk a sémák, XSL 
transzformációk és az XPath rejtelmeibe. Ahhoz, hogy e ka- 
landozásaink kézzelfoghatóak, kipróbálhatóak legyenek, 
nézzük végig milyen programok, eszközök állnak a rendelke- 
zésünkre, ha XML alapú fejlesztésekbe szeretnénk belevágni. 
A jövőbeli XML alapú fejlesztések teljes támogatására a 
Microsoft Visual Studio.NET lesz a legkényelmesebb integrált 
eszköz. Amíg azonban nincs (legalább fél év), addig is kell 
valamivel dolgoznunk. Milyen eszközökkel tehetjük ezt meg? 


Microsoft XML Parser 3.0 [1] 

ő mindennek a lelke, a mozgatórugója. Az XML parser egy COM 
komponens, amelybe számtalan funkciót belezsúfoltak. Mivel 
COM komponens, minden COM-ot támogató nyelvből és eszköz- 
ből használható, VB-ből, VBScript-ből (ASP), JavaScript-ből 
(ASP-ben, böngészőben), Visual Cs---ban, vagy akár Windows 
Scripting programokban. (Azt, hogy Office termékekből is hasz- 
nálható nem említettem, de természetesen azokból is működik) . 
A .NET framework alatt található XML Parser még nem teljes 
(ami nem is csoda, hisz még Beta 1 szinten van) , de a .NET nyel- 
vekből egyszerűen meghívhatók a COM komponensek, így 
egyelőre abban is az XML Parser 3.0-t érdemes használni. 

A parser-ben található szolgáltatásokat két nagy csoportra 
oszthatjuk: az egyik az XML DOM (Document Object Model) , 
a másik a SAX API (Simple API for XML). 

Az XML DOM célja, hogy egy XML dokumentumot beolvas- 
son, értelmezzen, és lehetővé tegye a: dokumentumban 
(XML fában) való mozgást és módosítást programozható 
felületeken keresztül. Azaz miután beolvasta XML csodán- 
kat, képesek leszünk programból új tagokat beleilleszteni, 
attribútumokat módosítani stb. Ugyanezzel a modullal le- 
het XSL fájlokat is beolvasni, majd egy XML dokumentum- 
ra végrehajthatjuk az XSL-ben leírt transzformációkat. 
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A DOM nagyon kényelmes kis XML állományok feldolgozásá- 
hoz, azonban több megabájtnyi XML fájlok feldolgozására 
nem megfelelő, mert beolvassa az egész XML fájlt a memóriá- 
ba, és csak utána értelmezi. Ez különösen kiszolgálóoldali fel- 
használásnál okoz nagyon hamar problémákat, ahol sok fel- 
használó egyszerre akarna nagy XML-eket értelmeztetni. 
Kiszolgálóoldalon, webalkalmazásokban hasznos lehet az 
alkalmazás indulásakor felolvasni és értelmezni a sokszor 
használt XML dokumentumokat, sémákat és XSL-eket. Kife- 
jezetten erre a célra találunk a komponensben olyan Free- 
Threaded DOM-ot, ami elviseli azt, hogy egyszerre sok web- 
lap egyszerre használja. 

Az előbb említett memóriaproblémákon tud segíteni a 
SAX. A DOM-mal ellentétben a SAX egymás után olvassa fel 
az XML forrás sorait, és előre meghatározott feltételek ese- 
tén egy eseménnyel jelzi a hívó program felé, hogy felolva- 
sott és értelmezett egy adag XML tagot. Ilyenkor a hívó 
program feldolgozza a kapott adatköteget, majd visszaadja 
a vezérlést az értelmezőnek. Ezzel a módszerrel tetszőleges 
méretű XML állományokat is feldolgozhatunk minimális me- 
mória felhasználásával, mert mindig csak az éppen feldol- 
gozás alatti dokumentumrész van a memóriában. Egy web- 
alkalmazásban ez nagyon kifizetődő tud lenni. 

Emellett a csomagban találunk egy HTTP-n keresztüli XML 
kommunikációra alkalmas objektumot is, melynek segítségé- 
vel HTTP protokollra ültetve (ezt szinte minden tűzfal szere- 
ti!) tudunk XML dokumentumokat küldeni a fogadó alkalma- 
zásoknak. Ez már a Webszervizek lehetőségét villantja fel! 
Az XML Parser type library-jét Microsoft XML, v3.0 néven talál- 
hatjuk meg a fejlesztőeszközökben. Részletes dokumentációt 
az MSDN library-ban találhatunk, illetve weben a [2] címen. 


XML fejlesztőeszközök, segédprogramok 

Az XML parser, mint alapkomponens nélkülözhetetlen, de 
sok egyéb eszközünk is van, amelyeket kihasználhatunk a 
fejlesztésekben. Lássuk ezeket! 


XML Notepad [3] 

Az XML nélküli testvéréhez hasonló bonyolultságú eszköz, a 
fejlesztőeszközök csúcsa, mellyel grafikus felületen szer- 
keszthetjük meg az XML fánkat. Első ránézésre elég félreve- 
zető a felhasználói felülete, azonban némi gyakorlattal jól 
használható kis program. Íme egy kép róla, működés közben: 


SZ Cikk11.xmi - XML Notepad B zol xi 
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A "3 Gyumolcsok 








nak tartalma síkba kiterítve. Tehát egy-egy tag, attribútum 
értékét a jobb oldalon írhatjuk be, míg a baloldalon jobb 
klikk, helyi menükkel hozhatjuk létre a gyerekelemeket, att- 
ribútumokat satöbbi. Az elkészült mű forrását megtekint- 
hetjük View/Source... menüpont alatt: 


View Current XML Source 





XKortek Forrasz"Csongrad" 
cKorte1 Szin-"Zold"3Kortec/Korte12 
cXKorte2 Szin-"Sarga"73 
c/Kortek; 
c/Magyan 
Vietnami; 
cNarancs23 
c/AVietnamb 
/Gyumolcsok? 


The current XML definition is well formed. 


Amellett, hogy láthatjuk az XML forrásunkat, még az is kiderül, 
hogy sikerült-e jól formázott dokumentumot összehoznunk. 


SOL Server XML View Mapper [4] 

Az októberi Tech.net különszámban már írtam az XML nézetek- 
ről, melyek nem mások, mint az SOL Server 2000 és az IIS 
együttműködésével előállt transzformációk, melyek a háttér 
SOL adatbázis adatait szolgáltatják tetszőleges felépítésű XML 
formátumban. Ehhez egy XML formátumú fájlt kell készíte- 
nünk, ami az adatbázismezők és a kimeneti XML dokumentum 
elemei között teremt kapcsolatot. Ez az XDR annotált séma. 
Az XML nézetek segítségével el lehet rejteni a forrásadatbázis 
szerkezetét, és tetszőleges XML formátumú kimenő adatokat 
tudunk generálni az SOL Server táblákból. A tipikus feladat, 
hogy kapunk egy sémát, ami leírja a kívánt XML adatok for- 
mátumát, és nekünk össze kell párosítani az SOL Server me- 
zőit-tábláit a kívánt XML dokumentum elemeivel. Ez nagyon 
mechanikus munka, és ebben segít az XML View Mapper. 

A program felhasználói felületének jobb oldalán láthatjuk az 
összeállítandó XML nézetünket, a baloldalon pedig egy létező 
SOL adatbázis tábláit és nézeteit. A két oldal mezői között 
fogd, és vidd módon lehet összerendeléseket teremteni. Az 
XML nézetben lehet logikai JOIN-okat is létrehozni, azaz olyan 
táblákat JOIN-olni, amelyek adatbázisszinten nincsenek össze- 
kötve. Ennek is elég bonyolult a formátuma, azonban az ehhez 
szükséges kódot is legenerálja a program. 





EE microsoft SOL Ser KEZET ZT TETT S NN zJDl2] 
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For Help, press Ft 





A baloldalon található az XML fa, a jobboldalon pedig an- 
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XML Lint [5] 

Ez egy nagyon egyszerű kis parancssori program, melynek 
segítségével ellenőrizhető, hogy egy XML dokumentum jól 
megformázott-e, valamint, hogy megfelel-e egy paramé- 
terként megadott DTD-nek vagy XDR-nek. 


MSXSL [6] 

Parancssori segédprogram, melynek segítségével XSLT 
transzformációkat tesztelhetünk, illetve sok állományra 
végrehajtathatunk. Azaz veszi a forrás XML dokumentumo- 
kat, végrehajtja rajtuk az XSLT fájlban kijelölt transzformá- 
ciót, és generál egy eredmény XML fájlt. 

Például, ha a forrásfájl, a.xml tartalma: 


c?xml version-c"1.0"?5 
cxsilTutorial 2 
ctitlesXSLC/titles 
dauthor2John SmithC/author2 


€/xsiTutorial: 


Az transzformálófálj, a.xsl tartalma: 


DEVELOPER XMLGESSÜNK 
€/updg:header2 
cupdg:syne 5 
Supdg:befores 
dcEmployees  EmployeeID-"$EmployeeID" /5 
£/updg:before2 
LZupdg:after5 
dcEmployees  LastName-"$LastName" /5 
£/updg:after2 
£/updg: sync? 
£/ROOT5 


Az összes, ebben a cikkben felsorolt telepítőcsomag és prog- 
ram letölthető a NetAcademia ftp szerveréről is a [8] címen. 


Zárszó 

Sorozatunk első részében belekóstoltunk az XML technológia 
alapjaiba. A következő részben megnézzük, mind ügyfél, mind 
kiszolgálóoldalon az XML dokumentumok feldolgozásának lehe- 
tőségét az XML DOM-mal. Addig is a [9] címen található pél- 
daalkalmazások segítségével bátran lehet tesztelni a jól formá- 
zott XML dokumentumokat, valamint ki lelhet próbálni saját, il- 


letve előre elkészített példa XSL transzformációkat. A jövőben 
is követjük ezt a jó hagyományt, és minden XML cikkünkhöz itt 
lesznek elérhetőek a példaalkalmazások és tesztprogramok. 


Sxsl:stylesheet version-"1.0" 
xmlns:xsl-"http://www.w3.org/TR/WD-xsl"5 


Sxsl:template match-"/"5 


Soczó Zsolt MCSE, MCSD, MCDBA 
NetAcademia Kft. 


cH1:cxsl:value-of select-"//title"/5c/H15 
cKH2oCxsl:value-of select-"//author"/5c/H25 
£/xs1l:template2 


£/xsl:stylesheet2 


A cikkben szereplő URL-ek: 


[1] MSXML Parser 3.0 Release 
http://download.microsoft.com/download/xml/Install/3.0/ 
WIN98Me/EN-US/msxml3.exe 

[2] XML Parser referencia http://msdn.microsoft.com/library/ 
psdk/xmlsdk/xml 9yg5.htm 

[3] XML Notepad http://msdn.microsoft.com/xml/NOTEPAD/ 


MSXSL-lel a transzformáció: 
msxsl a.xml a.xsl -o k.xml 


És a kimenet, a k.xml tartalma: 


download.asp 
ESZE kS aA es [4] SOL Server XML View Mapper 1.0 http://download.microsoft.com, 
5. a 
BOSTON ÉM EEBES ZTE download/SOLSVR2000/Install/1.0/NT5/EN-. up.exi 


[5] XML Lint http://msdn.microsoft.com/downloads/tools/ 
xmlint/xmlint.zip 

[6] MSXSL http://msdn.micri m/msdn-fi 
001/485/XSLTCommandLine.exe 

[7] XML for SOL Server 2000 Web Release 1 
http://download.microsoft.com/download/SOLSVR2000/Install/ 
1.0/W9X2KMe/EN-US/XML9o2Ofor9o20SOL.EXE 

[8] A fenti eszközök tükrözése a NetAcademia ftp szerverén 
ftp://ftp.netacademia.net/tools/xml 

[9] NetAcademia XML oldalak 
http://technet.netacademia.net/feladatok/xml 


XML for SOL Server 2000 [7] 

Az SOL Server 2000 XML támogatásának fejlesztésekor egy fon- 
tos cél kimaradt a végleges termékből - időhiány miatt. Így 
történhetett az meg, hogy az SOL Serverből jól kidolgozott, ké- 
nyelmes módon lehet elérni a tárolt adatokat XML formátum- 
ban XML nézetekkel és XML sablonokkal, addig visszafelé, az 
adatok módosítása még csak SOL Scriptből, az OPENXML segít- 
ségével lehetséges. Azaz közvetlenül XML formátumú leírással 
nem lehet adatokat beletuszkolni a szerverbe, XML nézeteken 
keresztül. Ezt a funkciót az XML for SOL Server 2000 csomag 
segítségével felokosított SOL Serveren lehet elérni. A bűvszó 
az updategram, amely lehetővé teszi a közvetlen, XML adatmó- 
dosító parancsok végrehajtását. Csak a teljesség kedvéért meg- 
mutatok egy updategram-on keresztüli SOL tábla módosítást, 
a részletes tárgyalásra külön cikket szánunk. 


AROOT xmlns:updg-"urn:schemas-microsoft-com: 
4. xml-updategram"5 
£updg:header2 

cupdg:param name-"EmployeeID"/5 


Supdg:param namez"LastName" /5 
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K: Egy SCSI merevlemezen üldögélő Windows 2000-t átmásoltam egy IDE 
lemezre. Norton Ghostot használtam, tehát a boot szektor, az MBR és 
minden más átvitelre került, az IDE partíció is aktív. Az új helyen azon- 
ban még sem indul el, kék képemyőzik. A hibaüzenet: INACCESSIB- 
LE BOOT DEVICE. Mintha nem ismemé fel a lemezt. Már mindent kijaví- 
tottam, a BOOT.INI-ben is átírtam Multi()-ra a menüpontot, mégsem ta- 
lálja. Mi lehet az oka? 

V: Az ok egyszerű. Ha egy konfigurációban nincs IDE lemez, 
akkor a Windows 2000 nem indítja el feleslegesen annak 
meghajtóját (ATAPI.SYS) sem. Másolás előtt ,meg kellett 
volna mutatni" neki az IDE lemezt, detektálta volna, s az 
ATAPLSYS is elindult volna. De még most sem késő, van egy 
megoldási lehetőség: a telepítő CD-ről indított Recovery Con- 
sole segítségével képesek vagyunk a halott NT-n módosításo- 
kat végezni, többek között eszközmeghajtókat beindítani. Ha 
nincs telepítve a Recovery Console, bootoljunk Windows 
2000 CD-ről, majd telepítés helyett válasszuk a ,Repair" 
üzemmódot, abból pedig a Recovery Console-t. Egy csodála- 
tos, karakteres ,operációs rendszerhez" jutunk, amely ismeri 
a legtöbb DOS parancsot (dir, copy stb.), és - korlátozottan 
ugyan, de - képes registrymatatásra is. Adjuk ki az 


ENABLE ATAPI SERVICE BOOT START 


Parancsot, ami átbillenti az ATAPI.SYS indítási értékét a re- 
gisztrációs adatbázisban, s az a következő rendszerindítás- 
kor elindul, így a Windows 2000 fel fogja ismerni a lemezt. 
Egyébként mindenkinek melegen ajánlom, hogy túlélőkész- 
letébe vegye fel a Windows 2000 telepítőlemezt, mert a Re- 
covery Console segítségével nemcsak halott Windows 2000 
boncolható, hanem Windows NT 4.0 is! Mi több, a Recovery 
Console jó előre feltelepíthető a gépekre, hogy probléma 
esetén azonnal, és gyorsan hozzáférhessünk. Telepítése: 


I1386NWINNT32 /CMDCONS 


Ennek hatására lefut egy minisetup, és feltelepíti a mintegy 
7 megabájtos , operációs rendszert", s felveszi a rendszerin- 
dító menübe, a BOOT.INI-be. Katasztrófa esetén tehát egy- 
szerűen csak kiválasztjuk a boot menüből, és már miénk is! 
Forrás: NetAcademia Windows 2000 lista 


K: Feltettük a levélbombák ellen védő Security patchet a vál- 
lalat számítógépein futó Outlook 98-akra. Roppant elégedett 
vagyok a védelemmel, talán túl jól is sikerült: azóta EXE csa- 
toláshoz semmilyen módon nem férek hozzá. De hogyan le- 
hetne kivételesen mégis leszedni az attachmentként érkező 
tiltott fájlokat? Vagyis egy konkrét levél vagy személy esetén 
hogy lehet letiltani a védelmet? 

V: Outlookkal sehogy. Ráadásul ezt a patchet le sem lehet 
venni. De van kerülőmegoldás: 
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Kérdezz, Felelek! 


1. Az Outlook Patch semmilyen hatással nincs az Oultook 
Web Accessre. Menj be böngészővel a levelesládádba, és 
töltsd le a kívánatos fájlt (http://tegéped/exchange) . 

- ol xi 


a] 
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89 Reply o Reply to all] 98 Forward 64 [23 968 ] 
Sent: Mon 2001. 03. 05. 1109 AM 





From: Marcell Foti 


To: Marcell Foti 

Ce: 

Subject: 

Attachments: A Attachments may contain viruses or scripts that are 


harmful to your computer. 


0 Futtassunk vírust OWA-val! :) 


2. Meg lehet kísérelni a patch átverését. Küldesd el ma- 
gadnak ismét az EXE-t, de a feladó nevezze át valami 
semleges kiterjesztésre, például semmi.aaa. Ez letölthe- 
tő, és visszanevezhető. 

Forrás: NetAcademia Exchange 2000 lista 


K: Honnan lehet , kitalálni", hogy egy ActiveX objektumnak 
milyen függvényei vannak? Az Outlook, Outlook Express és az 
Excel érdekelne. 
V: Ezek az információk általában megtalálhatók az msdn.micro- 
soft.com címen, de kézzel is kibányászhatók. Minden ActiveX 
objektumnak van úgynevezett Type Library-ja, ami némi inform- 
ciót nyújt az objektumról. Ezeket mindenféle ravasz API hívá- 
sokkal le lehet kérdezni. Kódolás nélkül pedig a konyhakész OLE- 
View eszköz használatával jutunk ezekhez az adatokhoz. Az OLE- 
View a platform SDK-ban és a Visual Studioban is megtalálható. 
E Ez: alla 





Be 
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0 Az OLEViIew munka közben 
Forrás: NetAcademia Msdev lista 


K: Mit tehetünk, ha az SOL Server beépített aggregátumfüggvé- 
nyei (Sum, Avg stb.) helyett másféle aggregátumot szeretnénk 
készíteni? Hogyan lehet szorzatfüggvényt használni? Az SOL 
2000 új felhasználói függvényei jók lennének, de SOL7 adatbá- 
zisban kell megoldani a feladatot. Mit lehet ilyenkor tenni? 
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V: Egyik listatagunk állt elő ezzel a megoldással, amely szorzás- 
ra valóban jó, azonban az SOL 2000 felhasználói függvényeinek 
rugalmasságát természetesen nem lehet pótolni natív trükkö- 
zéssel. Ha van egy táblánk, amelyben a , result" mező tartalmát 
kell összeszorozni, használhatjuk az alábbi megoldást: 


select id, exp(sum(log(result))) 
from tabla 
group by id 
Forrás: NetAcademia SOL2000 lista 


K: Hogyan lehet megtudni egy távoli gép MAC Addressét? 
V: PL. pingeléssel. A Ping előtt ugyanis lefut egy ARP kér- 
dés, amely a kezdeményező gépre bekéri a távoli masina 
MAC Addressét. Tehát így: 


PING gep 
ARP -A 


Vigyázat! Ha a távoli gép router túloldalán van, akkor ez a 
módszer a router MAC Addressét adja meg! 
Forrás: NetAcademia Windows 2000 lista 


K: Egy dual processzoros alaplapon jelenleg egy processzor- 
ral fut az NT4.0 . Most beletennénk a második procit, de at- 
tól félek, hogy a HAL cseréje miatt újra kell majd telepíteni 
az NT-t. Igaz ez? 

V: Nem igaz. A Windows NT Resource Kiten található az UP- 
TOMP.EXE eszköz, amely elvégzi a konverziót. Mellesleg 
összesen öt fájlt cserél le, amit kézzel is meg lehet tenni [2]. 
Az eljárás menete: 

1. Második processzor bedugaszolása 

2. Boot. Ilyenkor a két proci közül csak az elsőt látja az NT 
3. UPTOMP.EXE 

4. Reboot 

A műtét eredményességéről például a Task Managerrel győződ- 
hetünk meg, ahol a Performance fülön innentől két ablakocs- 
ka látható majd a processzor terheltségéről: a bal, meg a jobb. 


€ Windows NT Task Manager [IDE 
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K: Windows 2000 tartományom alatt a DNS Serverben meg- 
próbáltam ,, rendet rakni" azonban úgy tűnik, sikerült szét- 
vernem a Windows 2000 nélkülözhetetlen SRV rekordjait. 
Hogyan tudnék visszatérni az eredeti, hibátlan állapothoz? 
Zónafájlmentésem nincs! 

V: Ezt a feladatot bízzuk a Windows 2000-re! Induljunk 
tiszta lappal, töröljük ki a zónafájlból a még megmaradt 
roncsokat, majd a 


IPCONFIG /REGISTERDNS 
parancs segítségével vetessük vissza a hostrekordokat, végül a 


NET STOP NETLOGON 
NET START NETLOGON 


páros beregisztrálja a MSDCS, GC és a többi kívánatos 
bejegyzéseket. 
Forrás: NetAcademia Windows 2000 lista 


K: Ügyesen frissítgetünk Windows 2000-re, már az összes 
tartományvezérlőnk átállt. Most szeretnénk átállni Mixed 
módról Natív módra, de félünk, hogy ezzel elveszítjük a ré- 
gi, Win9X ügyfeleket. Mi lesz a PDC emulátorral, a NetBIOS 
támogatással, a WINS-sel? Lesz-e NTLM hitelesítés? 

V: A Natív és Mixed mód közötti különbségek egyike sem 
vonatkozik a kiszolgálók külső hálózati kapcsolataira. Gon- 
doljuk végig: a kompatibilitás jegyében mi mindent tettek 
a redmondi fejlesztők. Még a DOS-os kliensek is használha- 
tók! A Natív módra váltással ezek a szolgáltatások NEM tűn- 
nek el! Az egyetlen érezhető korlátozás az lesz, hogy töb- 
bé nem lehet a tartományba NT4-es Backup Domain Cont- 
rollert felvenni. 

Forrás: NetAcademia Windows 2000 lista 


K: A Windows 2000 Professional-ban hiába állítom be a magyar 
Regional Settings-et, a naptárban a hét szerdával kezdődik. 

V: Egy registry beállításon múlik az egész. Az [1] címről le- 
tölthető hetfo.reg fájl az alábbi módosításokat tartalmazza: 


([HKEY CURRENT USER(Control Panellinternationalj 
"iFirstDayofWeek"-"0" 


[HKEY USERSY.DEFAULT(Control PanellIinternationalj] 
"iFirstDpayOfWeek"-"0" 


Az első sor az aktuálisan bejelentkezett felhasználó naptá- 
rát állítja helyre, a második pedig az alapértelmezést. 
Ezután minden újonnan létrehozott felhasználónak hétfőn 
kezdődik a hét (pedig milyen jó volt még két napot otthon 


MG KKEZZRReeee—e—e.... Physical Memory (KJ————— á fal 

Handles 14270) Total 523632 Hz MLSETLKOZTTST E LÉ j 

Threads 5057! Available 51441 ]! Forrás: NetAcademia Windows 2000 lista 

Processes 45] ] FieCache 198201 [/ 

Commk Charge (K) ——] fr Kemel Memory (K)— .] EEZZZEZETHTEY 

Total 560728]! Total j A a" 
Limit si [rea 15456 [/ [1] ftp://ftp.netacademia.net/patch/w2k/hetfoire. 
Peak 631380 ( Nonpaged. 6852 / [21 http://support.microsoft.com/support/ 














(Mem Usage: 560728K / 1543580. / 


(CPU Usage: 97 
Forrás: NetAcademia Windows 2000 lista 


ÍProcesses: 45 
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MICROSOFT RESEARCH 


Gary Starkweather, a Microsoft egyik vezető kutatója sze- 
rint eljön még az a nap, amikor képernyő , tapéta" borítja a 
szobák falát, és a látvány bőségesen kárpótol majd minden- 
kit azért a kis nyűgért, amit ennek a , felragasztása" jelent. 


Olcsó húsnak nem mindig híg a leve 

Mit nem adnék érte, ha a szobám egyik falát így díszíthet- 
ném! Hát bizony több millió forintot nem. Százezernél már ta- 
lán nem hervadna le a mosoly az arcomról, de a legnagyobb 
sajnálatomra eddig egyetlen cég sem rukkolt elő elfogadható 
árú lapos képernyővel. És nyugodt lélekkel állíthatom, hogy 
nem a cinizmus szólt belőlem, hanem az átlagos fogyasztó. 
Sajnos, van itt egy-két probléma. A fali képernyő energiael- 
látása legalább akkora kihívás, mint a megépítése. A képek 
megjelenítéséhez és mozgatásához szükséges sávszélesség 
sem éppen szokványos tervezési eljárást kíván. Egy 108 x 72 
hüvelyk (kb. 274 x 183 cm) nagyságú, 300 dpi-s faliképernyő 
felbontása 32400 x 21600 képpont, így a képátviteli igény 
meghaladná az 50 gigaképpontot másodpercenként. Figye- 
lemreméltó számok. A kijelző elképesztően sok fényvisszave- 
rő vagy -kibocsátó alkotóelemből állna, ráadásul ezek össze- 
kapcsolása és energiaellátása sem magától értetődő feladat. 
Hiába bővelkedünk a műszaki megoldásokban, mindegyiknek 
megvan a maga baja. Az elölről vetítő kijelzők képére árnyé- 
kot vethet bárki, aki használja; a hátulról vetítőknek megle- 
hetősen nagy a területigénye, abból pedig soha sincs elég; 
az LCD klassz, de előállítása drága. Ezeknek a problémáknak 
a legtöbbjét megvizsgálta a Microsoft egyik kutatócsoportja, 
de a gyártási költségekkel ezidáig nem tudtak megbirkózni. 
Starkweather barátunk azonban nem az a visszariadós típus. 
(Szerencsére hiába mondták neki annak idején, hogy a lézer- 
nyomtató senkinek sem kell majd.) Mike Sinclair kutatótársá- 
val most éppen olyan miniatűr kijelzőképpontok kifejleszté- 
sén dolgozik, amelyekből tetszőleges nagyságú képernyők 
állíthatók össze. Nevezzük nevén a gyereket: a MEMS (Micro- 
ElectroMechanical Systems) technológiáról van szó. 


Trükkök a tükrökkel 

A MEMS technológiával olyan, mikroméretű eszközök készít- 
hetők, amelyek elektromos és mechanikus összetevőket öt- 
vöznek. Sinclair szerénysége bámulatos: állítása szerint 
még csak tanulja a MEMS-t, de már bemutatta saját készí- 
tésű, az emberi hajszálnál alig nagyobb vezérlő- és kapcso- 
lóelemeit. Most 40000 apró tükörből álló, hüvelykujj nagy- 
ságú kijelző elkészítését tervezi. Mindegyik tükörnek saját 
motorja és memórája lesz. Ha a memória tartalma 0, a tü- 
kör az egyik irányba térül, ha 1, a másik irányba fordul. A 
tükrök nagyon gyorsan váltanak irányt - hasonlóan a ver- 
senypályák eredményjelző tábláinak apró lemezeihez, - így 
a fénytörés elhanyagolható mértékű. Spékeljük meg min- 
dezt egy kis piros, kék és zöld lézerrel, és már el is készült 
a hihetelenül nagy felbontású kijelző, ami ráadásul olcsó, 
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Háló 
a falon 


nem rongálja a szemünket, és jó nagy képernyőt lehet be- 
lőlük összeállítani. 


A valóság sem mindig keserű 

Ha elkészíted, meg is veszik!" Ez a szlogen minden bizonnyal 
nem egy céget sodort már a csőd szélére, de legalábbis nagy 
bajba. Mary Czerwinski kijelentésével, miszerint a Microsoft a 
felhasználók érdekeinek szem előtt tartásában az egyik leg- 
jobb, valószínűleg sokan vitába szállnának. (Ebből rögtön ki is 
található, hogy hol kutató ő.) Ha netán elragadna valakit a 
kritikai érzéke, gondoljon talán más cégek termékeire is. Az 
előzetes piacelemzés semmi esetre sem érdem, ezért nem fog- 
juk megdicsérni a redmondi fenegyerekeket. De másért igen. 
Miközben a hardveres csapat egyre jobb megoldásokkal ruk- 
kol elő, Czerwinski a szélesvásznú vetítők felhasználóit ta- 
nulmányozza: Mit kezdenek ezzel a nagy felülettel a 17" 
monitorok után? Használják-e majd a szélét, és ha igen, ak- 
kor miért nem, de legfőképpen hogyan? 

Emellett egy másik projektben, a tevékenységek megszakí- 
tásának a munkafolyamatokra gyakorolt hatását is vizsgálja. 
Ez a párosítás első hallásra kissé talán elvontnak tűnik, de 
semmi esetre sem a véletlen műve: elég ehhez azt végiggon- 
dolni - mint ahogy ezt a cikk elején meg is tettük -, hogyan 
ingázunk a különféle alkalmazások ablakai között. 
Czerwinski szerint a nagy képernyőket kivetítő kis dobozok 
nemcsak egyszerűen ebben a minőségben foglalják majd a 
helyet az asztalunkon. A legtöbben térben tájékozódnak a 
legjobban, így az alkalmazások és dokumentumok háromdi- 
menziós környezetbe helyezett , ikonjait" valószínűleg előbb 
megtalálják, mint kétdimenziós megfelelőjüket egy hierar- 
chikus felépítésű mapparendszerben (not my favorites). 
Ezek a gondolatok a műszaki fejlődésben élen járó orszá- 
gokban is igazi víziónak számítanak, nálunk pedig még a 
14" monitorok kora sem áldozott le. Ne essünk azonban ab- 
ba a hibába, hogy nem vesszük észre az elkerülhetetlent. A 
mai fiatalok (mondom ezt 29 éves fejjel!) képesek párhuza- 
mosan akár több csevegőablakban is értelmesen beszélget- 
ni, miközben szól a rádió, és a holtidőben a házi feladatuk 
is elkészül. 

A jövőbelátás képességével megáldott Czerwinski azt állít- 
ja, hogy a nagy képernyőknek nagy jövője lesz. Én minden- 
esetre üresen hagyom a lakásomban az amúgy is üres, leg- 
nagyobb falat - egyelőre. És ha egyszer netán ilyen ,tapé- 
ta" lesz rajta, ígérem, hogy többet nem nézem meg a Vissza 
a jövőbe című filmet. 
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TechNet szemináriumok a Microsoft Magyarország szervezésében! 
Helyszín: BUDAPEST, Lurdy Ház, Hollywood Multiplex Mozi (1097 Budapest, Könyves Kálmán krt. 12-14.) 


.. A Windows 2000 alapú hálózatok biztonsági kérdései 
Időpont: 2001. 04. 04. 

Ezen az előadáson a Windows 2000 operációs rendszer nyújtotta biztonsági szolgáltatásokkal foglalkozunk. Egy 
egygépes rendszerből kiindulva a nap során fokozatosan eljutunk egy nagyvállalati rendszer címtár segítségével 
felügyelt, PKI infrastruktúrán alapuló rendszerig. Sok egyéb mellett lépésről-lépésre bemutatjuk, hogyan lehet 
engedélyezni az intelligens kártya alapú felhasználói bejelentkezést, hogyan kommunikálhatnak titkosítva a ki- 


szolgáló farm elemei egymással, és hogyan küldhetünk egymásnak titkosított vagy digitálisan aláírt levelet. 


Időpont: 2001. 04. 18. 
A szemináriumon egy tipikus Windows NT/2000 fájl- és nyomtatókiszolgálókat üzemeltető, Office-t és e-ma- 
ilt használó vállalati környezetből kiindulva fokozatosan építünk fel egy fejlett csoportmunka-, ismeretkeze- 


lő és kommunikációs megoldásokat alkalmazó rendszert. 


Microsoft Üzemeltetői Konferencia 

Időpont: 2001. 04. 25. 

A konferencia elsősorban üzemeltetési vezetőknek és rendszer üzemeltetőknek szól. Segítséget nyújt a nagy- és kö- 
zépvállalatok informatikusainak és rendszergazdáinak, hogy a már meglévő Microsoft technológiákra épülő rend- 
szereiket még megbízhatóbban és egyszerűbben üzemeltethessék. Szeretnénk bemutatni és átadni mindazt a tu- 


dást, ami a Microsoftnál és partnereinél az üzemeltetési és terméktámogatási gyakorlat során felhalmozódott. 


, akendszetrélügyetetekélndews 2000 KÖRNYEZETBEN 
Időpont: 2001. 05. 02. 
Az előadás a Windows 2000 alapú vállalati környezetek rendszerfelügyeleti és üzemeltetési kérdéseit tárgyal- 
ja. A gyakorlatias megközelítésű előadáson egy kiépített Windows 2000 Active Directory, Systems Manage- 
ment Server (SMS) 2.0 és Microsoft Operations Manager környezetben mutatjuk be az asztali gépek és alkal- 


mazások, illetve a kiszolgálók felügyeletét és a napi üzemeltetési teendőket. 


Időpont: 2001. 05. 16. 
Minden vállalat használ adatbáziskezelőt, de vajon kihasználja-e a felhalmozott üzleti célú adatokban rejlő 
információkat? Az előadások az adattárház kezelés folyamatának legfontosabb lépéseit tekintik át. Ismerte- 


tett technológiák: Data Transformation Services, OLAP kiszolgáló (Analysis Services), MDX, ADO DM. 


ri A MICROSOFT MAGYARORSZÁG SZAKMAI MAGAZINJA 
tech.net 2001. 03. 


46 


Ív Micrcsoft 
NE EB UZlb) E AFIED 


e E 


NetAcademia Kft. H-1105 Budapest, Ihász utca 13. Tel.:36 (1) 263-2732 Fax: 36 (1) 261-7145 E-mail: infor(pnetacademia.net 





NetAcademia nyári konferencia! 


A NetAcademia 2001. május 18-19-én, kétnapos konferenciát tervez a Balatonparton, Kene- 
sén. A konferencián sajnos csak 150 fő vehet részt, így előzetesen szeretnénk felmérni, elég 
lesz-e ez a hely az érdeklődőknek, avagy valami nagyobb helységet kell-e keresnünk. 


Minden érdeklődő előzetes jelentkezését várjuk a következő e-mail címre: 


taborCnetacademia.net Az előzetes jelentkezés nem számít megrendelésnek, 
egyszerű felmérést szeretnénk végezni, vajon mennyi résztvevőre számíthatunk. 


A tervezett program: 
Május 18. péntek 
10:00-12:00 Érkezés a konferenciaközpontba, ebéd 
13:30 A konferencia megnyitója, szekcióra való feloszlás. Esetleges 
problémák megbeszélése, szimulálása. (A szekció itt a különböző- 
levelezési listákat, a különbözőlevelezési listák témakörei szerinti 
feloszlást jelenti! Levelezési listáinkat megtalálja a 


http://lyris.netacademia.net címen) 
16:30-18:30 Szórakozás - azaz informális szekciózás 
19.00 Vacsora, az elsőnap tapasztalatainak összefoglalása a szervezők 


szemszögéből, esetleg a szekciók 1-1 kiragadott - érdekesebb - 
esetének a többiekkel való megosztása. 


Május 19. szombat 
10.00 Szekciózás, előadások 
12.00-13.00 Ebéd 
13.30-15.00 Még egy utolsó szekciózás 
15.00 A konferencia zárása 
16.00 — VÉGE 


A szekciózásokra igyekszünk megnyerni illusztris vendégeket, érdekes témákkal, de magánjellegű 
felvetéseknek, akár kiselőadásoknak is helyet kapnak majd! A konferencia részvételi díja, mely 
tartalmazza a szállás és az étkezés költségét körülbelül 20-22 ezer forint (4 AFA. sajnos... ) 


Kérjük, amennyiben felkeltettük érdeklődését, a mellékelt jelenzkezési lapot faxolja el kitöltve 
a 261-7145-ös faxszámra. Mivel csak előzetes felmérésről van szó, faxát nem tekintjük meg- 
rendelésnek. A konkrét megrendelés ügyében kollégáink a későbbiekben veszik fel a jelent- 
kezőkkel a kapcsolatot. 





Még ip zih ha egen 
GEZA ANZ UNA ERT 
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NetAcademia Kft. H-1105 Budapest, Ihász utca 13. Tel.:36 (1) 263-2732 Fax: 36 (1) 261-7145 E-mail: 


NetAcademia nyári konferencia 2001.05.18-19. 


Előzetes megrendelés 


Kérjük az alábbi megrendelőt kitöltve küldjék vissza a fent megadott faxszámra. 
Megrendelő cég neve: 


Résztvevő(k) neve: 


Számlázási cím: 
Telefon / Faxszám: 


E-mail cím: 


Dátum: 


Pecsét Cégszerű aláírás 


Megjegyzés: 


Fiall 








selejtmerv 
gyártásró 
encszer- 
felügyeletrr 
hálózatról (ZAK, 
AwW)? 
Feltörhetetlen 
hálózatról (C2)? 


Elérhetetlen, de megközelíthető célok. Az első kettő elérésében sajnos nem segít- 
hetünk. De a harmadik cél megközelítésében sokat tehetünk Önért. Világszínvonalú, 
egyedi Security tanfolyamainkon megtudhatja, mitől döglik a hacker! 
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1. Biztonsági technológiák 3. Hálózatunk védelme a támadásokkal szemben 
rendszergazdáknak, 3 nap biztonsággal foglalkozó szakembereknek, 3 nap 
e Titkosítási algoritmusok (DES, RSA, MD5 stb.) elmélete és gyakorlata e  Kalóz-eszközkészlet (Denial Of Service, Buffer 


e Az authentikáció biztonsága (Kerberos, NTLM, NTLMv2) 

s — A nyílt kulcsú titkosítási technológia nagyvállalati, gyakorlati alkalmazása . 
(Certificate Server, SmartCard, biometrikus azonosítás) 

e — Biztonságot növelő technológiák bevezetése (IPSec, VPN, LZTP Encrypting " 


Overrun, hálózatelemzés, trójai falovak, vírusok, jelszófeltörés, hátsó ajtók) 
A Windows 2000 biztonsági elemei (fájlrendszerek, regisztrációs adat- 
bázis, hálózati adatforgalom) 

Védekezés: tűzfalak, proxyk 


File System stb.) s — Aktív védekezés: Intrusion Detection 
4. Programozzunk biztonságosan! 
2. Biztonságos levelezőrendszer kialakítása MS Exchange alapokon programozók számára, 3 nap 
gyakorlott Exchange endszergazdák számára, 3 nap s — Elmélet: védett mód, kernel, memóriakezelés 
e Titkosítás és digitális aláírás az elektronikus levelezésben (S/MIME) s Programozási gyakorlatok, rosszul és jól megírt kódok 
e — Az Exchange Server védelme, adminisztratív szerepek, jogosultságok, s — A Buffer overrun hatásai user és (app es service)-4-kernel módban 
mentés, visszaállítás, journaling s — RFC implementation errors 
e tűzfal vs. Exchange Server, SMTP relay beállítások, spam védelem, SSL, 5 — JAVA, ActriveX, homokozó, scriptek 
TSL, nyílt kulcsú titkosítás felhasználása, MAPI, POP3, IMAP, OWA, LDAP s — Worm vírusok elemzése (lloveyou) 
protokollok veszélyei. e. CryptoAPI, Smart Card API 
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